Skip to main content
An API key lets software that is not a browser, such as a backend service, a script, a CI job or an MCP client, call MITHUNAI. Each key belongs to one organisation and holds one role, exactly as a person would.

​
Create a key

Only Owners and Administrators can create keys, and only from a signed-in console session. An API key cannot create, list or revoke keys, so a leaked key can never mint itself a replacement.
  1. Open API keys and select New API key.
  2. Choose What are you connecting?: your own app or script, or an AI tool over MCP (Beta). This picks the example you see next. It changes nothing about the key.
  3. Select Create API key, then copy the key now. It is shown once and cannot be retrieved later.
That is all you have to choose. The key is named after what it connects and the date, holds the Member role, and expires in 90 days. To change any of these, open More options before you create it:
  • Name says what uses the key, such as “Support portal integration”. It appears in your audit trail.
  • Role. Pick the narrowest that works: You cannot create a key with a role above your own.
  • Expires: 90 days (the default), 30 days, 1 year or Never expires. An expiring key limits how long a leaked credential stays useful.

​
Run the example

Beside the new key, the panel shows an example to copy in cURL, Python or Node, with your real API address, your real key and the first of your assistants that can answer. If you have several, choose which one. If none can answer yet, the example says so and uses a placeholder. Running it is how you test the key: it asks a question and prints the answer. The console has no test button, because that would send the secret back to the server. The examples hold your real key, so keep them out of anything you commit. For an MCP client, the MCP (Beta) tab gives the endpoint and a client configuration. See MCP.

​
Use a key

Send it as a bearer token:
A key always acts in the organisation it was created in. Each key has its own rate-limit budget, so one busy integration cannot exhaust another’s, unless both call from the same network address: see Rate limits.

​
Rotate a key

Rotation is two steps, so nothing breaks in between:
  1. Create a new key with the same role, and deploy it to the integration.
  2. Once the integration is using the new key, revoke the old one.
The Last used column shows whether the old key is still in use before you revoke it.

​
Revoke a key

Select Revoke next to the key on the API keys page. Revocation:
  • takes effect on the next request, with no delay or cache;
  • is permanent: a revoked key cannot be reactivated;
  • keeps the key in the list as revoked, so access reviews can see it existed.
A key also stops when the person who created it leaves: removing a member stops every key they created in your organisation, and lowering their role stops the keys whose role is now above theirs. If an integration depends on someone’s key, rotate it to a key of your own before they go.
If a key is exposed, in a commit, a log, a support ticket or a web page, revoke it first, then create a replacement.

​
Keep keys safe

  • Store keys in a secret manager, never in source code or a committed .env file.
  • Never put a key in a browser, a mobile app or any HTML. For websites, use the widget, which has its own public key.
  • Give each integration its own key, so you can revoke one without affecting the others.
  • Set an expiry where you can, and review Last used regularly to revoke keys nobody uses.

​
Errors

For the endpoints, see API keys in the API reference.
Last modified on November 3, 2026