Skip to main content
The REST API requires a Pro or Enterprise plan.
The Mintlify REST (Representational State Transfer) API enables you to programmatically interact with your documentation, trigger updates, embed AI-powered chat experiences, and export analytics data.

Endpoints

Common use cases

Authentication

Generate API keys on the API keys page in your dashboard. Each API key belongs to an organization—you can use keys across multiple deployments within the same organization. You can create up to 10 API keys per hour per organization. When you create a key, you can set it to expire in 7, 30, 60, or 90 days, or select No expiration. New keys default to 90 days. The API keys page shows an Expires in … badge for keys that expire within 7 days and an Expired badge for keys that have already expired. Expired keys stop working, so rotate or replace them before the expiration date. Mintlify uses two types of API keys, each scoped to a different set of endpoints:

Admin API key

Use the admin API key for deployment, triggering the agent, and analytics endpoints. Admin API keys begin with the mint_ prefix. The admin API key is a server-side secret. Do not expose it in client-side code.

Assistant API key

Do not directly embed the assistant API key in client-side code. Any visitor who extracts the key can call the assistant message endpoint on your behalf, consuming credits and potentially triggering overage charges.For production deployments, proxy requests that use an assistant API key through your own backend and store the key as a server-side environment variable. Routing requests through a proxy also lets you add rate limiting, authentication, and bot protection to prevent abuse.
Use the assistant API key to authenticate requests to the assistant, search, and page content endpoints. Assistant API keys begin with the mint_dsc_ prefix.
Search documentation and page content requests do not consume credits. Assistant message requests use credits and can incur overages.

Restrict keys by IP address

Optionally restrict an API key to a list of allowed IP addresses or CIDR ranges. When a key has an allowlist, requests from any other IP address return a 403 response. Both admin and assistant API keys support allowlists. Set the allowlist when you create a key on the API keys page in your dashboard. You set the allowlist for the lifetime of the key when you create it. To change the allowlist, you must create a new key. If you don’t set an allowlist, the key accepts requests from any IP address. Allowlist entries support:
  • IPv4 and IPv6 addresses, for example 203.0.113.5 or 2001:db8::1.
  • CIDR ranges, for example 198.51.100.0/24 or 2001:db8::/48.
You cannot use catch-all entries like 0.0.0.0/0 and ::/0. Use IP allowlists when a stable set of egress IPs call your API key. For example, a CI/CD runner, a static NAT gateway, or your backend server. Avoid allowlists for keys used from developer laptops or other environments with changing IPs.

Restrict admin keys by scope

Optionally restrict an admin API key to read or write scopes. Scopes apply only to admin API keys. Set scopes when you create a key on the API keys page in your dashboard. You set the scopes for the lifetime of the key when you create it. To change the scopes, you must create a new key. If you don’t set any scopes, the key can call every admin endpoint. Mintlify derives the required scope from the HTTP method of the request. A key with write also satisfies read, so ["read", "write"] and ["write"] both allow every endpoint. Requests that require a scope the key does not have return a 403 response. The scope only accepts read and write. Any other value returns a 400 response at key creation.

Set an expiration date

Optionally set an expiration date on any API key at creation. After the expiration timestamp passes, requests using the key return a 403 response. Both admin and assistant API keys support expiration. Set the expiration on the API keys page in your dashboard. You set the expiration for the lifetime of the key. To change it, you must create a new key. If you don’t set an expiration, the key never expires. The expiration must be a future ISO 8601 timestamp. Past or invalid timestamps return a 400 response at key creation. The expiration returns as expiresAt when you list keys, or null for keys with no expiration. Use expirations for short-lived credentials, such as CI/CD tokens, external contractors, or one-off scripts. Rotate long-lived keys by creating a replacement, updating your integrations, and deleting the old key.