Third-party applications ("is_first_party": false) that initiate a user-delegated access request, including an audience parameter for specific Auth0 system APIs, receive an error response with the following message:

Client "[THIRD_PARTY_CLIENT_ID]" is not authorized to access resource server "[AUTH0_SYSTEM_API_AUDIENCE]".

Currently restricted system APIs include:

• Management API
• My Account API
• My Organization API
• Multifactor Authentication (MFA) API

User-delegated access requests include requests performed via the authorization endpoint (/authorize) and other endpoints that include user authorization, such as the device authorization flow.

• Authorization
• Third-Party Applications
• User-Delegated Access to Auth0 APIs

Auth0 introduced these restrictions, starting April 2026, as part of several improvements to third-party application functionality. The restrictions apply to both new and existing third-party applications.

The Auth0 system APIs, subject to these restrictions, primarily provide functionality intended for first-party applications or grant access to sensitive user account operations that should not be allowed via third-party applications, so the error response is expected and unavoidable if the use case requires this type of access.

However, the error may surface during the implementation of use cases that do not strictly require user-delegated access to a third-party application, in which case it may not be a blocker. For example, in the following scenarios, there is an alternative path forward.

Scenario A - Unintentional Inclusion of Auth0 Restricted API Audience

Reusing code from another use case or sample applications can result in including a restricted API audience even though the third-party application does not need to call that API. In this case, either:

• Omit the audience parameter when initiating the requests.
• Replace the system API audience with the /userinfo audience.

Scenario B - Misrepresentation of Application as Third-Party

If an application is a third-party application ("is_first_party": false) but the tenant's owners have direct control/oversight over its behavior, it may be possible to mark it as a first-party application instead.

Scenario C - Requiring Non-Opaque Access Tokens

Since the access tokens issued for some system APIs, like the Management API, are signed JWTs that any other system can technically decode and verify their signature, the inclusion of such an audience may be motivated by the need for a non-opaque access token.

Given that access tokens should be used only with the APIs matching their requested audience, any use case requiring non-opaque access tokens should rely on custom API audiences instead. To learn more, read Set Up APIs.