Authentication

The AISAR API uses Bearer tokens backed by Laravel Sanctum personal access tokens. Every token belongs to its own service account, and each service account is bound to a single company — every request made with the token runs in that company's context.

Request header

Send the token in the Authorization header on every request:

Authorization: Bearer 123|xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The token format is {id}|{plaintext} (Sanctum's standard format). Send it in full, including the part before |.

Creating and revoking a token

A token is created in the company cabinet: Settings → Systems → API. This requires the Business plan (the api feature) and the api-token.create permission. AISAR provisions a new service account (a dedicated User flagged as a service account) and issues it a token — the plaintext value is shown only once, at creation time.

The same page manages tokens through REST endpoints (you can also call them directly, from an existing token/session):

Creating a token returns a token field with the full Bearer value — it is only ever returned in that response and is never shown again. Revoking (DELETE) removes the service account together with all of its tokens — the action is irreversible.

Create a separate token per integration/agent — this lets you revoke access for one consumer without affecting the others.

Token permissions

The service account is created with the Admin role in the company, so a token has full access to the workspace by default. Individual endpoints additionally check specific permissions (for example conversation.create to send messages, conversation.view to upload files, template.view to read templates) — these are documented per endpoint in the REST reference and in the message-sending walkthrough.

Rate limiting

Every Bearer token is limited to 3000 requests per 60 seconds. The limit is counted per token — one token's traffic does not affect another's.

Every response (except requests without a Bearer token) carries these headers:

When the limit is exceeded the server returns 429 with a body and an extra Retry-After header (seconds until reset):

{
  "message": "Too Many Requests.",
  "retry_after": 42
}

A few endpoint groups (for example heavy broadcast and AI-agent operations) carry an additional, narrower limit — in that case a 429 can arrive before the overall 3000/min budget is exhausted.

Handling 401 and 429

• 401 Unauthorized — the token is missing, invalid, or has been revoked. Body: {"message": "Unauthenticated."}. Check the Authorization header and confirm the token wasn't revoked in the cabinet.
• 429 Too Many Requests — the limit was exceeded. Wait retry_after seconds (or the Retry-After header value) before retrying, ideally with exponential backoff on repeated hits.

The full status table and error format are covered in the Errors guide.