API error 106 "The user does not represent an authorized developer" for manager accounts where I am Super Admin

Question

I'm using the Microsoft Advertising API v13 (REST) with delegated OAuth (msads.manage) and a developer token.

My login is Super Admin on several manager (agency) accounts, all linked to one login via "Manage multiple users". The API works for one of my customers (SearchAccounts by my UserId returns only that customer's account, and reads/reports there succeed). But for the other manager customers — where I am also Super Admin — Campaign Management calls fail:

Call: GetCampaignsByAccountId (REST Campaigns/QueryByAccountId)

Result: HTTP 403, OperationError Code 106 UserIsNotAuthorized, message: "The user does not represent a authorized developer."

So SearchAccounts / GetCustomersInfo only ever return the one authorized customer, and any Campaign Management request against accounts under the other (linked) manager customers returns error 106 — even though I'm Super Admin on all of them.

Question: how do I get my developer token / user recognized as an authorized developer for these other linked manager customers, so the API works across all the manager accounts my login administers? Is this a per-customer setup or a support action? I can share the developer token, UserId, CustomerIds/AccountIds and a TrackingId privately.

Thanks!

Answer 1

Hello Karol Pietrzak,

Greetings! Thanks for raising this question in the Q&A forum.

This is not a developer token approval or authorized-developer whitelist issue. The behavior you're describing (works for the one customer you signed up under directly, fails for the other manager customers even though the UI shows Super Admin) matches how Microsoft Advertising scopes Super Admin permissions on linked customers. When your login is connected to additional manager accounts through "Manage multiple users," each of those connections carries its own CustomerLinkPermission value, either Administrative or Standard. Super Admin permissions are only fully honored on linked customers when that link permission is Administrative. If it is Standard, the UI still shows you as Super Admin, but Campaign Management calls against that customer's accounts are rejected with error 106, while the customer where you originally signed up (your directly-owned customer) keeps full permissions regardless of link type. That is why SearchAccounts and GetCustomersInfo only ever surface the one authorized customer even though you can see all of them in the web UI.

Confirm the link permission on each customer Call GetUser with UserId left nil using your OAuth token and developer token. The response returns a CustomerRole array with one entry per customer you can access. Inspect the CustomerLinkPermission field for each entry, not just the role name. The customer that works will show either no restriction (your own signup) or Administrative, while the failing ones will most likely show Standard.

Request Administrative link permission from each manager account owner If a customer shows Standard, that link needs to be upgraded by a Super Admin who has direct (non-linked) access to that manager customer. This is done through the Microsoft Advertising web UI under Accounts & Billing > Manage multiple users, by editing the access level granted to your login for that specific customer and setting it to Administrative rather than Standard.

Alternatively, get provisioned as a direct user on each customer Instead of relying on the linked login convenience feature, ask the owner of each manager account to send you a direct user invitation into that CustomerId using SendUserInvitation with a Super Admin RoleId, scoped to that customer. Direct users provisioned this way do not depend on CustomerLinkPermission and behave the same as your originally-owned customer.

Verify the CustomerId header matches the target account on every call Make sure each GetCampaignsByAccountId request sends the CustomerId header for the manager customer that actually owns the AccountId you're querying, not a single CustomerId reused across all calls. A mismatched header alone produces the same 106 error independent of link permission.

Re-test and escalate with TrackingId if it still fails After confirming Administrative permission or direct provisioning, re-issue the token if needed and retry. If error 106 persists on a customer you've confirmed is Administrative or where you're a direct user, open a support case through the Microsoft Advertising API support channel and include the TrackingId from the failing response along with the specific CustomerId and UserId, since at that point it would need investigation on the account setup itself.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.