Authentication

Base URLs

All API requests are made to one of the following base URLs depending on your environment:

Environment	Base URL
Production	`https://api.appdna.ai`
Sandbox	`https://api.appdna.ai`

Both environments share the same base URL, https://api.appdna.ai — the API-key prefix (adn_test_ vs adn_live_) selects sandbox vs production. Never use production API keys in sandbox or development environments. Use test keys during development.

API Key Types

AppDNA uses two distinct key types, each designed for a different integration surface.

1. SDK API Keys

SDK API Keys authenticate mobile SDKs (iOS, Android, Flutter, React Native) against the ingestion and config-bundle endpoints.

Field	Description
`public_key`	Unique public identifier, prefixed `adn_live_` (production) or `adn_test_` (sandbox)
`secret_key_hash`	Hashed secret counterpart
`environment`	`production` or `sandbox`
`status`	`active` or `revoked`

Send the public key in the x-api-key header:

curl -X POST https://api.appdna.ai/api/v1/ingest/events \
  -H "Content-Type: application/json" \
  -H "x-api-key: adn_live_a1b2c3d4e5f6" \
  -d '{ ... }'

2. Dashboard Session Tokens

Dashboard and analytics endpoints (analytics, webhooks, settings, etc.) are authenticated with the Firebase session token of the signed-in console user — not a standalone REST API key. Send the Firebase ID token as a Bearer token along with headers identifying the organization and application in scope:

curl https://api.appdna.ai/api/v1/analytics/kpis \
  -H "Authorization: Bearer <firebase-id-token>" \
  -H "x-tenant-id: <organization-id>" \
  -H "x-app-id: <application-id>" \
  -H "Content-Type: application/json"

The server verifies the Firebase token and resolves it to the caller’s user, organization, and role. Access to the requested organization and application is enforced against the caller’s memberships.

Authentication Levels

AppDNA enforces four authentication levels depending on the endpoint:

Public

No authentication required. Used for health checks and public endpoints.

Endpoint	Purpose
`GET /api/v1/ingest/health`	Ingestion health check
`GET /api/v1/auth/signup-enabled`	Check if signup is enabled
`POST /api/v1/auth/login`	User login
`POST /api/v1/auth/signup`	User registration

SDK Key

Requires the x-api-key header. Resolves the key to an app_id and tenant_id pair. Used by the mobile SDKs.

Endpoint	Purpose
`GET /api/v1/sdk/bootstrap`	SDK bootstrap
`POST /api/v1/ingest/events`	Event ingestion
`GET /api/v1/sdk/config-bundle`	Download config bundle
`GET /api/v1/sdk/config-bundle/version`	Check bundle version

Customer (JWT)

Requires a valid Firebase session token plus x-tenant-id and x-app-id headers. The caller must be a member of the x-tenant-id organization, and x-app-id (when sent) must be an application of that organization — otherwise the request is refused with 403. Routes that name the organization in the path (/api/v1/orgs/{orgId}/…) authorize that organization (and the {appId} in the path, which must belong to it); the headers are not used there. A malformed organization or application id in the path is answered with 404. The server resolves the caller to:

{
  tenantId: string;   // Organization ID
  appId: string;      // Application ID
  userId: string;     // Authenticated user ID
  role: 'owner' | 'admin' | 'member' | 'viewer';
}

Used by all dashboard API endpoints (analytics, webhooks, settings, etc.).

Super Admin

Requires a valid session token carrying the super-admin claim, which the server verifies before granting access. Used exclusively for platform-operator endpoints (tenant management, platform billing, etc.).

Super Admin endpoints are not available to regular API consumers. They are reserved for platform operators.

Managing API Keys

API keys are managed from the AppDNA Console:

Navigate to Settings in the left sidebar
Select the SDK Keys tab
Use Create key, choose the environment, accept the SDK End User License Agreement and confirm

When you create a new SDK API Key, the secret key is shown only once, right after you create it, with a button to copy it. Store it securely — you will not be able to retrieve it again.

Owners, admins and members of the organization can create a key while its subscription is active; viewers cannot, and the Create key button is not shown to them. AppDNA super admins can create one too, whatever the subscription’s state. While the organization is suspended for an unpaid invoice, an owner, admin or member with an AppDNA staff account (an @appdna.ai or @appdna.agency email address) can also create one. Only owners and admins of the organization, and AppDNA super admins, can revoke one; the Revoke button is shown only to them. The SDK Keys tab lists only the app’s pk_live_ / pk_sandbox_ keys, to every member of the organization. It never lists an adn_live_ / adn_test_ key: those are listed — by name, prefix and last four characters only — under Settings → SDK → API Keys (/settings/sdk/api-keys), whose list only owners and admins can read. Revoke an adn_ key there (owners and admins, while the subscription is active), or with DELETE /api/v1/sdk/api-keys/{id}, where {id} is the key’s id from GET /api/v1/sdk/api-keys — the list that page reads. Revoking it stops it on every endpoint that takes an SDK key, config-bundle downloads and event exports included. While the organization is suspended, revoking an adn_ key — on that page or with DELETE — answers 403; the only exception is an AppDNA staff account (an @appdna.ai or @appdna.agency email address) when the suspension is for an unpaid invoice. A pk_ key’s Revoke on the SDK Keys tab has no subscription check, so the organization’s owners and admins, and AppDNA super admins, can revoke one during a suspension. Revoking is permanent: a key revoked while the organization’s SDK access is suspended for an unpaid invoice — a pk_ key by any of those, or an adn_ key by AppDNA staff — stays revoked when access is restored.

Rotating Keys

Rotation applies to the adn_live_ / adn_test_ keys listed under Settings → SDK → API Keys (/settings/sdk/api-keys), for owners and admins while the subscription is active. Use Rotate on the key there, or:

POST /api/v1/sdk/api-keys/{id}/rotate

{id} is the key’s id from GET /api/v1/sdk/api-keys. The response carries the new key in key — shown only once — with the old key’s name, environment and permissions. The old key is not revoked at once: it keeps working for 24 hours, then every endpoint that takes an SDK key answers 401 to it — event ingestion, bootstrap, push, billing, config-bundle downloads and the other SDK endpoints alike. Move your apps to the new key within those 24 hours. To cut the old key off sooner, Revoke it. Rotating the old key a second time creates another new key but does not extend the old key’s 24 hours; once they have passed, rotating it answers 409 (“the grace period is over — revoke the key”): the old key no longer works, and Revoke is the only action left for it. Rotating a revoked key answers 409 as well; create a new key instead. The pk_live_ / pk_sandbox_ keys under Settings → SDK Keys (/settings/sdk-keys) have no rotation: create a new key, move your apps to it, then revoke the old one.

Rate Limits

Rate limits are set by your plan; they are not configurable per app. Limits are per minute. Events (/ingest/events and /ingest/identify; an identify counts as one event):

Plan	Per organization (all keys)	Per SDK key
Starter	10,000	10,000
Pro	50,000	50,000
Autopilot	200,000	200,000
Enterprise	No limit	1,000,000
No plan	No limit	10,000

Other SDK endpoints (bootstrap, push-token registration, billing, location autocomplete, Option Set pages) are limited per device, as 300 requests a minute for each SDK key and caller IP address (an IPv6 address counts by its /64), and per SDK key across all devices:

Plan	Per SDK key: location autocomplete	Per SDK key: every other endpoint above
Starter or no plan	1,500	3,000
Pro	5,000	10,000
Autopilot	15,000	30,000
Enterprise	50,000	100,000

Each of these counts separately, except that the billing endpoints (verify, restore, entitlements) share one count. Billing requests also count toward the organization’s event limit. When a limit is exceeded, the API responds with HTTP 429 Too Many Requests and a Retry-After header. The SDK keeps events that were refused with 429 in its queue and retries them with exponential backoff.

You have successfully configured authentication when your SDK can call the bootstrap endpoint and receive a valid response with your orgId and appId.

​Base URLs

​API Key Types

​1. SDK API Keys

​2. Dashboard Session Tokens

​Authentication Levels

​Public

​SDK Key

​Customer (JWT)

​Super Admin

​Managing API Keys

​Rotating Keys

​Rate Limits

Base URLs

API Key Types

1. SDK API Keys

2. Dashboard Session Tokens

Authentication Levels

Public

SDK Key

Customer (JWT)

Super Admin

Managing API Keys

Rotating Keys

Rate Limits