Skip to main content
An API key (rsk_...) is how your applications authenticate to MeshAPI. It is also the unit that carries limits, spend caps, model access, and usage attribution — so managing keys is how you control what each application is allowed to do. This page covers the key-management API. For using a key to authenticate a request, see Authentication.
Key management uses a user JWT — your dashboard session token — not an rsk_ key. An inference key cannot create or modify keys, by design: a leaked key must not be able to mint more.

​
Creating a key

The plaintext key is returned once, in the key field of the create response, and is never retrievable again — only a hash is stored. Capture it at creation or you will have to issue a new one.

​
Fields

rpm above 1,000 or rpd above 1,000,000 are rejected with 422.

​
Managing keys

DELETE is a soft delete: it sets the key’s status to suspended. The key stops working at the inference layer immediately, but the record and its usage history are preserved. There is no hard-delete endpoint — this keeps historical usage attributable.

​
Pinning the API version

A key can carry an api_version — the dated contract every request made with it receives, unless the request sends its own X-Mesh-Version header. Useful when the calling code is not yours to change, or when a whole integration should sit on one version.
Send null to clear it. In the dashboard it is the key’s API Version field. See API versioning for what a version covers and which ones are served.

​
Model allow-lists

allowed_models restricts a key to a named set of models. It is the cleanest way to stop a cheap application reaching an expensive model.
An allow-list silently breaks features that route to models you didn’t list:
  • model: "auto" — the Auto Router picks from your allow-list. If none of its candidates are listed, routing fails.
  • Web search — /v1/web/search checks against its own model pin. An allow-list that omits it disables web search for that key.
Neither failure is obvious from the error. If a feature stops working right after you set an allow-list, this is why. Include the models those features depend on, or leave the key unrestricted.

​
Org and team keys

Assigning org_id or team_id makes a key part of a shared structure: it draws on the org’s shared balance and inherits the org’s and team’s limits, resolved minimum-wins alongside the key’s own. Attaching a routing_policy_template_id requires the key to belong to an org — templates are org-scoped, and a key with no org gets a 422. See Organizations & Teams for the surrounding model.