Skip to main content
API keys authenticate programmatic requests to the Jinba Toolbox API — executing a tool, managing ToolSets, or reading run history. Keys are scoped to an organization, grant Member-level access to that organization’s resources, and are bound to one ToolSet environment (default unless you choose another one).

​
How API Keys Work

All API keys use the jtb_ prefix. When you create a key, the full key value is shown in the creation dialog. Afterwards the list shows only a masked prefix (the first 12 characters, e.g. jtb_abc12345...); the copy button next to it retrieves the full key again for keys created after key encryption was introduced. API keys are tied to the organization where they were created. A key for Organization A cannot access resources belonging to Organization B (except for executing public tools, which any valid key can do).

​
Creating an API Key

1

Navigate to API Keys

Go to API Keys in the organization sidebar. You will see the list of existing keys (if any).
2

Click Create Key

Click the Create API Key button at the top of the page. A modal will appear.
3

Enter a Name and Environment

Give the key a descriptive name to identify its purpose (e.g. “Production Backend”, “CI/CD Pipeline”, “Local Development”). This name is for your reference only and does not affect the key’s permissions.Choose the Environment the key connects to (default: default). Executions made with this key use that ToolSet environment’s variables and active version.
4

Copy the Key

After clicking Create Key, the full API key is displayed. Copy it immediately and store it in a secure location.
Treat the key as a secret. If it was created before key encryption was enabled on your Toolbox, it cannot be retrieved again later.
5

Done

Click Done to close the modal. The new key will appear in the list with its name, masked prefix, environment, issuer, last used date and creation date.

​
API Key List

The API Keys page displays a table with the following columns:

​
Deleting an API Key

To delete a key, click the delete action next to the key in the list. A Delete API Key confirmation dialog will appear. Once deleted:
  • The key is immediately invalidated.
  • All API requests using this key will return a 401 Unauthorized error.
  • The action is permanent and cannot be undone.
Members can delete only the keys they issued themselves; Owners and Admins can delete any key in the organization.
Deleting a key does not affect past run records or data. It only prevents future API calls using that key.

​
Permissions

API keys do not have individual scopes. Every key acts with the Member role of its organization: it can read, create, update, delete and publish ToolSets and tools, run published tools and call MCP endpoints, and read runs and credits. Operations that need a signed-in user — testing draft code (/test), publishing versions, creating, revealing or deleting API keys — and Owner/Admin-only operations (webhooks, purchasing credits, deleting others’ keys) are not available to API keys.

​
Using API Keys

​
REST API

Include the key in the Authorization header:

​
TypeScript SDK

Pass the key when creating the SDK client:

​
MCP Endpoint

When connecting an AI agent to a ToolSet’s MCP endpoint, provide the API key as part of the connection configuration. The MCP endpoint URL is shown on the ToolSet’s Tools tab when the MCP switch is on and a version is published. The Connect with JinbaApp button there creates (or reuses) a key named JinbaApp Connection ({environment}) for you.

​
Where API Keys Are Managed

All API keys belong to an organization. Two console pages manage the same keys:

​
Best Practices

  • Use descriptive names — Name keys by their purpose and environment (e.g. “Production API Server”, “Staging CI”) so you can identify which key to revoke if needed.
  • Rotate keys regularly — Create new keys and revoke old ones periodically to limit the impact of a potential leak.
  • Never commit keys to source control — Store keys in environment variables or a secrets manager.
  • Use separate keys per environment — Create distinct keys for development, staging, and production.
  • Revoke unused keys — If a key is no longer needed, revoke it immediately. Check the “Last Used” column to identify dormant keys.
  • Use one key per environment profile — A key is bound to a ToolSet environment, so create separate keys for default and any additional environments you add.