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.