AdRoll User Management API Guide

Auth method: OAuth 2.0

Setup steps

1. Register an application in the AdRoll developer portal to obtain a client_id and client_secret.
2. Direct users to the AdRoll OAuth 2.0 authorization endpoint to obtain an authorization code.
3. Exchange the authorization code for an access token via the token endpoint.
4. Include the access token as a Bearer token in the Authorization header of API requests.

User object field mapping is not yet verified for this app.

Endpoint coverage is not yet verified for this app.

• Rate limits: AdRoll does not publicly document specific rate limits for its API.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate-limit documentation found. Contact AdRoll support for current limits.

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: No webhook documentation for user-management events found in official AdRoll developer or help center docs.

• Alternative event strategy: Poll the AdRoll API or use IdP-side event hooks if SCIM provisioning is configured.

• SCIM available: Yes
• SCIM version: 2.0
• Plan required: Not documented
• Endpoint: Not documented

Limitations:

• AdRoll's SCIM endpoint URL is not publicly documented; it is typically provided during SSO/SCIM setup within the AdRoll admin console or via support.
• SSO must be configured as a prerequisite before SCIM provisioning can be enabled.
• Specific supported SCIM operations (create, update, deactivate) are not enumerated in public documentation.
• No IdP-specific connector documentation (Okta, Entra, Google Workspace, OneLogin) is publicly listed by AdRoll.

SCIM provisioning (user lifecycle automation): SAML must be configured first - AdRoll does not support just-in-time provisioning via SAML alone.

Once SAML is active, retrieve the SCIM base URL and PAT bearer token from the AdRoll admin console (these are not published in developer docs).

Enter both into your IdP's SCIM provisioning configuration.

With SCIM active, user creation, updates (name, email, permissions), and deactivation in the IdP propagate automatically to AdRoll.

Note: some IdPs handle email address changes by deactivating the old account and creating a new one rather than updating in place

verify this behavior with your specific IdP before relying on it in an identity graph sync.

OAuth 2.0 for Ads API access: Register an application in the AdRoll developer portal to obtain client_id and client_secret.

Redirect users to the AdRoll authorization endpoint with response_type=code, exchange the returned code for an access_token at the token endpoint, and pass it as a Bearer token on subsequent requests.

Scopes are limited to advertising operations;

no user-management scopes are documented.

Do not attempt to use this token against SCIM endpoints.

Enable SCIM User Provisioning

1. Configure SSO for your AdRoll organization via the AdRoll admin console (SSO is a prerequisite for SCIM).
2. Navigate to the SCIM provisioning section in the AdRoll admin console to retrieve the SCIM base URL and bearer token.
3. Enter the SCIM base URL and token into your IdP's SCIM provisioning configuration.
4. Test provisioning by creating or updating a user in your IdP and verifying the change is reflected in AdRoll.

Watch out for: The SCIM endpoint URL and credentials are only surfaced inside the AdRoll admin UI after SSO is active; they are not available via the public developer API.

Authenticate with AdRoll Ads API via OAuth 2.0

1. Register an app in the AdRoll developer portal to get client_id and client_secret.
2. Redirect the user to the AdRoll authorization URL with response_type=code and your client_id.
3. Capture the returned authorization code and POST it to the token endpoint to receive an access_token.
4. Use the access_token as a Bearer token for subsequent Ads API calls.

Watch out for: OAuth 2.0 access is scoped to advertising operations only; no user-management scopes are documented.

The primary integration trap is assuming the OAuth 2.0 Ads API can be used to manage users or query identity state - it cannot. AdRoll's public API has no user-management endpoints, and OAuth scopes do not extend to provisioning operations.

Any identity graph that attempts to resolve AdRoll user state via the Ads API will return no usable identity data.

SCIM is the correct path for user lifecycle automation, but it carries its own caveats: the SCIM endpoint URL and bearer token are only surfaced inside the AdRoll admin UI after SSO is active, and are not available through the developer portal or public documentation.

This means SCIM cannot be bootstrapped programmatically - it requires a manual setup step in the console before any automated provisioning can begin.

Webhooks for user-management events are not available. There is no documented event stream for user creation, deactivation, or role changes originating from AdRoll itself.

For an identity graph that needs to reflect real-time AdRoll access state, the only reliable signal path is IdP-side events (e.g., Okta or Entra lifecycle hooks) feeding into SCIM, not any outbound notification from AdRoll. Plan for IdP-driven push rather than AdRoll-driven pull in any integration architecture.