Bearer authentication
#Send the full secret in Authorization: Bearer <key>. Cookies do not authenticate public API requests. Neither a query-string key nor an x-api-key header substitutes for the Bearer header.
Keys are bound to the workspace and its owner. A key cannot create a browser session, manage other API keys, or perform account-security operations. Project endpoints require a project ID belonging to that workspace and owner.
Permissions
#Permissions are independent. A key with generate does not automatically have read or write. Every scope listed on an endpoint is required.
| Scope | Allows |
|---|---|
read | Read workspace, project, reporting, content, and connection metadata. |
write | Create and edit project resources and content. |
generate | Use paid AI features and enqueue measurement, audit, opportunity, or content work. |
publish | Approve exact content versions and request provider delivery. |
integrations | Inspect provider resources, configure connections, and manage crawler credentials. |
Generation requires write + generate. Publishing requires write + publish. Provider resource inspection requires read + integrations. Include read too when your workflow needs to poll state or reconcile edits.
The API adds no separate pricing tier. Existing plan capacity, feature entitlements, and paid AI entitlement checks still apply.
Key lifecycle
#Workspace API access starts disabled and requires the owner's explicit opt-in. New keys expire after 1–365 days; the default is 90 days. A workspace can have at most 20 unexpired, unrevoked keys.
The secret is shown once. Searchly stores its SHA-256 digest and identifying prefix. Create a replacement key before an integration's key expires, then revoke the old key after updating the integration.
Revocation takes effect on the next request. Disabling workspace API access blocks its keys until the owner enables access again; it does not revoke them. Expired keys and keys belonging to banned, deleted, or anonymous owners are rejected.