Once you have the key, authenticate every request by adding the X-API-Key header with the key’s full
value. No other session data is needed — no cookie, no Bearer token.
A real example, listing your own keys:
curl -X GET "https://YOUR_DOMAIN/api/v1/auth/api-keys" \ -H "X-API-Key: aa_YOUR_FULL_KEY_HERE"Response (200, shortened real example):
[ { "id": "985d256e-9809-...", "name": "My integration", "prefix": "aa_1b2e1ebd", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T05:36:27Z", "is_active": true, "owner_type": "user", "allowed_origins": [], "created_by": "admin@your-business.com" }]A company key (section 5) authenticates in exactly the same way, with no session or personal credentials — the tenant’s service account responds with its own keys (real example):
curl -X GET "https://YOUR_DOMAIN/api/v1/auth/api-keys" \ -H "X-API-Key: aa_9fe72924…"Response (200, shortened real example — note "owner_type": "tenant"):
[ { "id": "8a0b0f78-7b25-...", "name": "AK-18 fix round 1 demo", "prefix": "aa_9fe72924", "scopes": ["tenant:config.manage", "tenant:content.manage", "tenant:self.manage"], "expires_at": null, "last_used_at": "2026-08-23T06:28:37Z", "is_active": true, "owner_type": "tenant", "allowed_origins": [], "created_by": "admin@your-business.com" }]Note — What an API key does NOT allow
It authenticates calls to the REST API with its sealed role’s permissions (section 7) — nothing more. Specifically: it isn’t for logging into the Platform’s web interface (that’s still email + password, or Google), it isn’t the same as WhatsApp/Telegram’s “Channel-linked access” (Manual 51, a different mechanism based on two-factor verification), and it doesn’t grant access to see someone else’s key or another tenant’s keys.