Unbounce User Management API Guide

Auth method: OAuth 2.0 (Authorization Code flow) or API Key (passed as query param or HTTP Basic password)

Setup steps

1. Register an OAuth application at https://developer.unbounce.com to obtain a client_id and client_secret.
2. Redirect users to https://api.unbounce.com/oauth/authorize with response_type=code, client_id, redirect_uri, and scope.
3. Exchange the returned authorization code for an access_token via POST to https://api.unbounce.com/oauth/token.
4. Include the access_token as a Bearer token in the Authorization header for all API requests.
5. Alternatively, use an API key (found in Unbounce account settings) as the HTTP Basic Auth password with an empty username.

Required scopes

Get authenticated account

• Method: GET
• URL: https://api.unbounce.com/accounts/self
• Watch out for: Returns the account associated with the OAuth token, not a list of sub-users.

Request example

GET /accounts/self
Authorization: Bearer {access_token}

Response example

{
  "id": "acc_abc123",
  "name": "Acme Corp",
  "email": "owner@acme.com",
  "timeZone": "America/New_York",
  "created_at": "2022-01-15T10:00:00Z"
}

List sub-accounts

• Method: GET
• URL: https://api.unbounce.com/accounts/{account_id}/sub_accounts
• Watch out for: Sub-accounts are organizational units, not individual user records. User seat management is done in the Unbounce UI.

Request example

GET /accounts/acc_abc123/sub_accounts?count=50&offset=0
Authorization: Bearer {access_token}

Response example

{
  "metadata": {"total": 3},
  "sub_accounts": [
    {"id": "sub_001", "name": "Client A"}
  ]
}

Get sub-account

• Method: GET
• URL: https://api.unbounce.com/sub_accounts/{sub_account_id}

Request example

GET /sub_accounts/sub_001
Authorization: Bearer {access_token}

Response example

{
  "id": "sub_001",
  "name": "Client A",
  "created_at": "2023-03-01T08:00:00Z"
}

List pages in sub-account

• Method: GET
• URL: https://api.unbounce.com/sub_accounts/{sub_account_id}/pages
• Watch out for: Pagination uses 'count' (not 'limit') and 'offset' parameters.

Request example

GET /sub_accounts/sub_001/pages?count=50&offset=0
Authorization: Bearer {access_token}

Response example

{
  "metadata": {"total": 12},
  "pages": [
    {"id": "pg_001", "name": "Summer Campaign"}
  ]
}

Get leads for a page

• Method: GET
• URL: https://api.unbounce.com/pages/{page_id}/leads
• Watch out for: Leads are form submission records, not Unbounce platform users.

Request example

GET /pages/pg_001/leads?count=100&offset=0
Authorization: Bearer {access_token}

Response example

{
  "metadata": {"total": 200},
  "leads": [
    {"id": "lead_001", "email": "user@example.com"}
  ]
}

• Rate limits: Unbounce does not publicly document specific rate limit thresholds or tiers in their developer docs as of the last known update.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented in official sources. Implement exponential backoff on 429 responses as a precaution.

• Pagination method: offset

• Default page size: 50

• Max page size: 1000

• Pagination pointer: offset and count

• Webhooks available: Yes

• Webhook notes: Unbounce supports webhooks triggered on form submissions (lead events). Configured per-page in the Unbounce UI or via the API.

• Alternative event strategy: Poll GET /pages/{page_id}/leads for new lead data if webhooks are not suitable.

• Webhook events: form_submission (lead created)

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• No native SCIM endpoint documented by Unbounce.
• SSO (SAML) is available on Enterprise/Concierge plans via Okta, Entra ID, and OneLogin, but SCIM provisioning is not natively supported.
• User provisioning must be done manually through the Unbounce UI or via IdP-side workarounds.

Three practical API scenarios are supported by the documented endpoints.

First, auditing the sub-account hierarchy: authenticate, call GET /accounts/self for the master account_id, then paginate GET /accounts/{account_id}/sub_accounts using count and offset (max page size 1000) until metadata.total is exhausted

note this returns organizational units, not user seat records.

Second, exporting leads: retrieve page IDs via GET /sub_accounts/{sub_account_id}/pages, then paginate GET /pages/{page_id}/leads per page;

no bulk export endpoint exists, so high lead volumes require many sequential requests.

Third, real-time lead ingestion via webhook: webhooks fire on form_submission events and are configured per-page in the UI or API

there is no global webhook registration endpoint, so programmatic coverage of all pages requires per-page configuration.

Audit all sub-accounts under a master account

1. Authenticate via OAuth 2.0 or API key.
2. GET /accounts/self to retrieve the master account_id.
3. GET /accounts/{account_id}/sub_accounts?count=1000&offset=0 to list all sub-accounts.
4. Paginate using offset until metadata.total is reached.

Watch out for: This lists organizational sub-accounts, not individual user seats. Individual user management is not available via API.

Export leads from all pages in a sub-account

1. GET /sub_accounts/{sub_account_id}/pages to retrieve all page IDs.
2. For each page_id, GET /pages/{page_id}/leads?count=1000&offset=0.
3. Paginate each page's leads using offset until metadata.total is exhausted.
4. Aggregate results for export.

Watch out for: High lead volumes require many paginated requests; no bulk export endpoint exists.

Receive real-time form submissions via webhook

1. In the Unbounce UI, navigate to the target page and configure a webhook URL under Integrations.
2. Unbounce will POST lead data to the configured URL on each form submission.
3. Validate the incoming payload and store or forward the lead data.

Watch out for: Webhooks are configured per-page, not globally. There is no API endpoint to programmatically register webhooks for all pages at once.

The most significant API trap is conflating sub-accounts with users. GET /accounts/{account_id}/sub_accounts returns client or organizational groupings, not individual seat records - building an identity graph from this endpoint alone will produce an incomplete and misleading picture of who has access to what.

OAuth tokens are scoped to the authorizing account owner with no per-user token or impersonation model, which limits the granularity of any access audit. Rate limits are undocumented; implement exponential backoff on 429 responses defensively.

Pagination uses the non-standard 'count' parameter (not 'limit') alongside 'offset' - cursor-based pagination is not available.