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.

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.

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.

Definition versions#

The 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 for the complete request and response reference, and errors and retries for recovery.