REST API OAuth2 authentication error when posting localized expense claims in EMEA region

We’re experiencing OAuth2 authentication failures when posting expense claims through the REST API for employees in certain European countries. The issue is intermittent but consistent for specific country codes (DE, FR, IT).

Our integration uses standard OAuth2 flow with client credentials grant. When posting expenses for US/UK employees, everything works fine. However, for EMEA locations with localized expense categories, we get 401 Unauthorized errors.


POST /api/v2/expense/claims
Authorization: Bearer eyJhbGc...
HTTP/1.1 401 Unauthorized
{"error":"insufficient_scope",
 "error_description":"Missing localization claims"}

We’ve verified API permissions in Infor OS Portal - the service account has Expense.Write and Localization.Read scopes enabled. The JWT token decodes correctly but wondering if there are additional locale-specific scopes needed for multi-country expense posting. Has anyone encountered similar authentication issues with localized financial transactions?

Let me provide the complete solution since you’ve identified the root causes. Your OAuth2 authentication errors stem from three interconnected configuration gaps that affect localized expense posting:

1. OAuth2 Token Configuration - Missing Localization Scopes Your JWT claims were missing country-specific authorization. In Infor OS Admin Console, navigate to Security > Service Accounts > [Your Integration Account] > API Permissions. Under the “Localization Scopes” section (often collapsed by default), you must explicitly enable each country code your integration supports: DE (Germany), FR (France), IT (Italy). This adds locale-specific claims to your JWT token like locale:DE:expense.write. Without these claims, the API gateway rejects requests for localized expense categories even though you have the base Expense.Write permission.

2. Tenant Localization Provisioning As Petra identified, your Infor CloudSuite tenant had DE/FR/IT locales in “pending” status rather than “active”. This is common for new tenants or when expanding to additional countries. Go to Tenant Settings > Localization > Active Locales and verify all required countries show “Active” status with Expense Management module enabled. If any are pending, contact Infor Support to complete provisioning (typically 24-48 hours). The API will return 401 errors for unprovisionned locales regardless of OAuth2 configuration.

3. Token Refresh After Configuration Changes Critical point: After enabling new localization scopes, existing OAuth2 tokens don’t automatically inherit the updated claims. You have two options:

  • Wait for natural token expiration (default 3600 seconds for client credentials grant)
  • Force immediate refresh by calling the token revocation endpoint:

POST /oauth2/revoke
token={your_access_token}&
token_type_hint=access_token

Then request a new token - the JWT will now include the locale-specific claims.

Verification Steps:

  1. Decode your new JWT token (use jwt.io) and verify claims include locale:DE, locale:FR, locale:IT in the scope array
  2. Test API calls for each country code - should now return 200/201 instead of 401
  3. Monitor your integration logs for any remaining locale-related errors

The key takeaway: Infor OS requires explicit locale authorization at both the service account level (OAuth2 scopes) and tenant level (provisioned locales). The generic Expense.Write scope only covers non-localized or default locale operations. Multi-country financial transactions need country-specific JWT claims that match your tenant’s active localization configuration.


This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

I’ve seen this before. The error message “Missing localization claims” is the key - your JWT token needs to include country-specific scopes. Check if your OAuth2 token request includes the locale parameter. For EMEA operations, you need to request scopes like Expense.Write.DE or Expense.Write.FR explicitly, not just the generic Expense.Write.

Confirmed this resolves our German expense posting failures — enabling DE and FR localization scopes in Infor OS Admin Console’s Service Accounts API Permissions section fixed our JWT claims immediately.

Thanks Marco. I checked our token request and we’re only requesting base scopes. Question: do we need separate OAuth2 clients for each country, or can we request multiple locale scopes in a single token? Our architecture currently uses one service account for all regions.

You don’t need separate clients. The issue is in your scope configuration in Infor OS. Navigate to Admin Console > Security > Service Accounts, edit your integration account, and under API Permissions you’ll see a “Localization Scopes” section that’s probably collapsed. Expand it and enable the specific country codes your integration needs to support. This adds the locale claims to your JWT automatically without changing your token request code.

Also worth checking your Infor OS tenant configuration. We had a similar problem where the localization module wasn’t fully provisioned for certain countries. Go to Tenant Settings > Localization and verify that Germany, France, and Italy are listed as active locales with expense management enabled. If they’re missing or in “pending” status, your API calls will fail even with correct OAuth2 scopes. We had to open a support ticket to get additional locales activated on our tenant.

Petra - you were right! Checked our tenant config and DE/FR/IT were in pending status. Opened ticket #CS-2847 and Infor support activated them within 24 hours. Now seeing those locales in the API permissions section.

Good catch on the tenant config. One more thing to watch - when you enable new locale scopes, existing OAuth2 tokens don’t automatically get updated claims. You need to either wait for token expiration (default 3600s) or force a refresh by revoking the current token through the Infor OS API.