# Authentication and limits

Authenticate server requests with an API key from the workspace that owns or can access the API. Send it in the `Authorization` header to the API origin supplied by the saved connection details.

```http
Authorization: Bearer <API_KEY>
```

The console uses your signed-in browser session. Your server integration uses an API key; browser cookies are not server credentials.

## Create a scoped key

Open **API keys** in your workspace and select the permissions your integration needs. The secret is shown once. Save it in your server's secret store before leaving the creation screen.

| Scope | Permitted work |
| --- | --- |
| `read` | Read API connection details, definitions, and version contracts; discover MCP tools. |
| `run` | Execute an accessible API through REST or MCP. |
| `results` | Retrieve saved build results and recorded run details or delivered results. |

Creating a key from an API's detail page requests `read`, `run`, and `results`, restricts it to that API, and sets a 30-day expiry. Workspace key creation supports an expiry of 1–730 days. Check the issued key's permissions, access, and expiry before deploying an integration.

## Restrict private API access

In workspace key creation, leave private pipeline restrictions unselected for access to all workspace private APIs, including future ones. Select specific pipelines to restrict the key to that fixed set. Public catalog access remains available in either mode, subject to the key's scopes.

A key restricted to selected APIs does not automatically gain access to a newly created API. Existing keys retain their own restrictions. Use a separate key for each integration so you can change its access or revoke it independently.

## Store, rotate, and revoke

Keep keys out of URLs, browser bundles, source control, screenshots, and logs. Supply them to server processes through your deployment's secret storage.

For a controlled replacement, create a new key, update the integration's secret, verify a bounded request, and revoke the old key. Direct key rotation invalidates the previous secret, so coordinate that operation with the application using it. If a creation request times out, inspect the key inventory before submitting another one.

Revoke an exposed key promptly and review its recorded usage. Expired or revoked keys are rejected on subsequent requests.

## Source-specific limits

The generated contract defines accepted inputs and maximum values. Collection APIs can support `max_pages` to bound collection pages and `detail_limit` to bound detail enrichment; zero disables detail enrichment. Search APIs can instead require a constrained `query`. Copy the exact example for your saved API.

Account capacity and workspace balance can also constrain execution. Respect a returned `Retry-After` delay and reduce concurrency when appropriate. Do not increase collection limits automatically after an error.

## Keep request identity separate

An API key identifies the caller. An `Idempotency-Key` identifies one intended execution. Customer workspace runs require both headers. Save the idempotency key with the request and reuse it only to recover that same execution. Read [idempotency and recovery](/docs/idempotency/).

## Definition versions

The [quickstart](/docs/quickstart/) sends `expected_version` to guard the active definition. Keep the full version and schema in your integration configuration. On a version conflict, review the updated contract before changing that configuration.

See [Run an API](/docs/run-api/) for the complete request and response reference, and [errors and retries](/docs/errors/) for recovery.