apikey HTTP header.
Calls APIs use a different base URL:
https://{appId}.call-{region}.cometchat.io/v3 (note call- instead of api-). Authentication still uses the apikey header.Management APIs use a different authentication mechanism —
key and secret headers, not the apikey header. See the Management APIs overview for details.API Key Scopes
CometChat supports two API key scopes:| Scope | Dashboard Name | Permissions |
|---|---|---|
fullAccess | REST API Key | All REST API operations: create/update/delete users, groups, messages, manage settings, etc. Use server-side only. |
authOnly | Auth Key | Can only create users and generate auth tokens. Intended for quick demos and prototyping. |
Making Authenticated Requests
Include the API key in theapikey header (all lowercase):
The HTTP header name is
apikey (lowercase). In JSON response bodies, the
property is apiKey (camelCase). HTTP headers are case-insensitive by spec;
JSON properties are case-sensitive.Auth Tokens
Auth tokens authenticate end-users (not server-side calls). The flow:- Your backend creates a user via REST API (using
fullAccesskey) - Your backend creates an auth token for that user via
POST /users/{uid}/auth_tokens - Your client app uses the auth token to log in via the CometChat SDK
Acting on Behalf of Users
Some endpoints support theonBehalfOf header, which lets a server-side call act as a specific user:
onBehalfOf is required, optional, or not supported varies per endpoint — check each endpoint’s documentation.
Security Best Practices
- Store API keys in environment variables or a secrets manager, never in source code
- Use
fullAccesskeys only on your backend server - Rotate API keys periodically via the API Keys API
- Generate auth tokens server-side and pass them to clients
- Use HTTPS for all API calls (enforced by CometChat)