Skip to main content
Answer

Inconsistent tenant selection with REST API using OAuth Authorization Code flow

  • September 18, 2025
  • 3 replies
  • 86 views

We’re integrating with a multi-tenant Acumatica (MYOB Advanced) instance. There are two companies (CompanyOne and CompanyTwo). For each tenant, I created a separate Connected App with its own client ID and secret.

Setup:

  • Using OAuth Authorization Code flow

  • Generating an access_token for each tenant’s Connected App

  • Using that token to call the REST API

Issue:

  • REST API calls sometimes return data from the wrong tenant.

  • For example, calling with CompanyOne’s token occasionally still returns data from CompanyTwo.

  • Behavior is inconsistent: if both tokens have expired and I refresh them, tenant separation works correctly for a while, but later the API “sticks” to CompanyTwo again.

Best answer by Abhishek Niikam

Hi

  • Make every REST call “cookie-free”.

  • In Bruno, open the Cookies panel (bottom-left for the request/collection) and delete any cookies for your domain, especially ASP.NET_SessionId. Bruno explicitly supports adding/sending/deleting cookies; use that UI to ensure none are sent. Bruno Docs

  • Verify no Cookie: header is going out.
    Bruno’s Timeline shows request headers, send your GET once and confirm there’s no Cookie header in the outbound request.

  • Reproduce to be sure.

  1. Clear Bruno cookies for the domain.

  2. Call /entity/... with CompanyOne token → check data.

  3. Call again with CompanyTwo token → check data.

    If you deliberately add back an old ASP.NET_SessionId cookie and re-send, you’ll see how it “sticks” to the cookie’s tenant (that’s the behavior you were hitting intermittently).

and you are right. Bruno is persisting the session cookie, and that’s interfering with Acumatica’s tenant resolution. If you strip cookies, you should be fine.

 

I hope this helps!

3 replies

Forum|alt.badge.img+2

Hello ​@madan, You may follow this steps:

  • Do not mix auth styles. Never call /entity/auth/login (cookie login) in the same client/session that you use OAuth tokens. If you must test both, use separate clients or clear cookies between runs.
  • Use tenant header explicitly: Company-Name: CompanyOne OR Company-Id: <tenantID>
  • Always include company/branch identifiers in API payloads
  • Ensure your HttpClient or request library does not store cookies across calls.(UseCookies = false) OR 
    const headers = {
      'Authorization': `Bearer ${tenantToken}`,
      'Company': tenantId,
      'Branch': tenantBranch,
      'Cache-Control': 'no-cache'
    };

     

  • Token decoded and verified against client_id@Tenant.  

 

I hope this helps!


  • Author
  • Freshman I
  • September 23, 2025

I should clarify a couple of details about my setup:

  • I’m only using the https://company.myobadvanced.com/identity/connect/token endpoint to generate the access token (via the Authorization Code flow). No SOAP login involved.

  • For testing, I’ve mostly been using the Bruno API client. I’m still investigating, but it looks possible that Bruno might be persisting session cookies (ASP.NET_SessionId) between requests, which could be affecting tenant selection. When I use Rails’ HTTP client, the behavior seems more consistent.

So this might be related to how the API client handles cookies in addition to the OAuth token.


Forum|alt.badge.img+2
  • Jr Varsity III
  • Answer
  • September 23, 2025

Hi

  • Make every REST call “cookie-free”.

  • In Bruno, open the Cookies panel (bottom-left for the request/collection) and delete any cookies for your domain, especially ASP.NET_SessionId. Bruno explicitly supports adding/sending/deleting cookies; use that UI to ensure none are sent. Bruno Docs

  • Verify no Cookie: header is going out.
    Bruno’s Timeline shows request headers, send your GET once and confirm there’s no Cookie header in the outbound request.

  • Reproduce to be sure.

  1. Clear Bruno cookies for the domain.

  2. Call /entity/... with CompanyOne token → check data.

  3. Call again with CompanyTwo token → check data.

    If you deliberately add back an old ASP.NET_SessionId cookie and re-send, you’ll see how it “sticks” to the cookie’s tenant (that’s the behavior you were hitting intermittently).

and you are right. Bruno is persisting the session cookie, and that’s interfering with Acumatica’s tenant resolution. If you strip cookies, you should be fine.

 

I hope this helps!