A Microsoft API that provides programmatic access to Microsoft Advertising to manage large campaigns or to integrate your marketing with other in-house systems.
Escalate this to Microsoft Advertising Support as a sandbox identity-association investigation, supplying both tracking IDs and the Microsoft Advertising user system identifier so the backend team can distinguish UserNotFound from token or account-state validation.
Error 105 does not identify a single root cause. It represents AccountInactive, InvalidAccessToken—including credentials for the wrong environment—or UserNotFound.^1^ Your successful token acquisition establishes that the OAuth authorization flow completed, but it does not establish that Microsoft Advertising sandbox resolved that Microsoft identity to the expected sandbox user.
Submit the escalation
Contact Microsoft Advertising Support and categorize the case as:
Microsoft Advertising API → Sandbox → Authentication → Error 105 / Microsoft identity mapping
Microsoft specifically directs cases involving sensitive account details or unresolved API authentication failures to Advertising Support. For errors 105 and 106, its escalation checklist requests the Microsoft Advertising login system identifier in addition to the request and response evidence.^2^
Include:
- Environment and operation
- Sandbox
- Customer Management v13
- Exact operation used, preferably a minimal
GetUserrequest - SOAP and REST both reproduce the failure
- Identity information
- Redacted Outlook login address
- Confirmation that it is an
outlook.compersonal Microsoft account - Sandbox customer ID and user system identifier
- Active lifecycle status and assigned Super Admin role
- Invitation acceptance date/time, if available
- OAuth and application information
- Application/client ID
- Authorization-code flow
- Requested scope
- Token issuance timestamp and expiry—not the access or refresh token
- Tenant/authority used
- Entra application’s supported account type
- Reproduction evidence
- UTC timestamp
- Full sanitized request and response
- Failed Microsoft OAuth tracking ID
- Successful Google OAuth tracking ID
- Statement that the same sandbox user/customer can be queried through Google OAuth
- Statement that Microsoft OAuth fails consistently through both SOAP and REST
- Requested backend checks
- Resolve the Microsoft token’s identity claims to the sandbox user record.
- Check whether the sandbox authentication service returns an internal
UserNotFoundor account-state result. - Verify that the Microsoft identity and Google identity are not attached to conflicting sandbox user records.
- Check service telemetry for the failed tracking ID and compare it with the successful request.
- Repair or relink the sandbox identity association if it is stale or inconsistent.
Do not send access tokens, refresh tokens, client secrets, or unredacted authorization headers.
Why further permission changes are not the next step
Sandbox requires separate credentials, sandbox endpoints, and—when Microsoft OAuth is used—an MSA created with an outlook.com address. It supports the universal sandbox developer token and requires the application’s own client ID.^3^ Those conditions, plus token transport, invitation acceptance, account status, permissions, SOAP structure, and both endpoint styles, have already been tested.
Also, insufficient entity authorization normally produces code 106 rather than code 105. An OAuth token carries the same account access and roles that its user has in the Microsoft Advertising UI.^4^ Therefore, repeating administrator consent or assigning Super Admin again is unlikely to discriminate this failure.
The fact that Google OAuth succeeds does not prove that Microsoft OAuth maps to the same underlying sandbox identity. Microsoft Advertising supports both providers, but the access token represents the selected provider’s user identity.^5^ Only Microsoft Advertising Support can correlate the supplied tracking ID with the backend identity-resolution result.
References