Project API keys
How to open the list
On the General page, find the API card and click Settings.

This opens the project API key page.
Each key card shows:
- name;
- masked prefix;
- granted permissions;
- Active, Inactive, or Expired status;
- creation date;
- last-used date or Never;
- expiration date or Never expires.
Expired status is determined by the expiration date even if the key itself was not disabled.
Daily API quota
The “API requests today” card shows usage, the current limit and the remaining requests. All API keys and external OAuth integrations in the project share the quota. The default allowance is 100,000 requests per day, resetting at 00:00 Moscow time. Viewing keys and other actions in Cabinet do not consume it.
To add requests, click “Increase limit” and select an addon on the tariffs page. The button is available to members with billing management permission. The first level adds 100,000 requests per day for ₽1,000 per month. The addon is billed and renewed with the tariff. Applying an increase preserves the requests already used that day.

The limit applies to external requests for project data, including requests from an AI client connected through Senler.io MCP. It counts HTTP requests to the API, not chat messages or MCP tool calls.
- Reads, each list page and retries consume the quota when admitted for execution. Input errors after access checks also count.
- Requests rejected by initial authentication and permission checks do not count. A server
5xxresponse refunds one request. - Account and application management requests do not consume the project quota. Calls to Senler.io through the standard tools of agents running within Senler also do not consume the external API quota. If your own service separately calls the API using a key or OAuth, its requests count under the usual rules.
When the quota is exhausted, the API returns 429 with error.name = api.daily_quota_exceeded. The request is not executed and does not increase usage. The X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers contain the limit, remaining requests and reset time in Unix seconds; Retry-After on 429 gives the seconds until reset. Wait until that time or increase the limit. Creating another key for the same project does not reset usage.
If quota accounting is temporarily unavailable, the API returns 503 with error.name = api.quota_unavailable and does not execute the action. Retry later with a delay. See SDK error handling for an example of reading errors and headers.
How to create a key
Click Create API key.

On the creation page:
- Enter a name.
- In Permissions, keep only the access required by the integration.
- Optionally set an expiration date. An empty field creates a key without an expiration date.
- Click Create API key.
After successful creation, a dialog displays the full value. Click Copy and save the key in secure storage. After the dialog is closed, the list displays only its prefix; the full value is no longer available in the interface.
How permissions work
Permissions are grouped by entity. Select all adds every available optional permission, including write permissions; Deselect all removes only optional permissions.
The required project permission is locked in the selector and preserved during creation and editing. This is enforced by the form, so it cannot be removed.
Use the smallest sufficient permission set. Do not include the full key in documentation, messages, or support requests.
Editing
Click the edit icon for the relevant key. On the edit page, you can:
- change the name;
- change permissions;
- enable or disable the key using the status switch.

The expiration date cannot be changed on the edit page. After saving, requests use the new status and permission set.
Deletion
Click the delete icon for the required key.

Verify the key name in the dialog and confirm with Delete. Requests using the deleted key can no longer authenticate.

If the key may have been exposed, delete it and create a new one instead of merely renaming it.
If an integration receives 401 or 403
Check in this order:
- the integration uses the full current key value;
- the key is active and has not expired;
- the key belongs to the correct project;
- the key has permission for the requested operation;
- after rotating the key, the integration actually saved the new value.