Zintara API authentication: workspace-bound keys and route scopes

Define the decision

The reviewed API implementation issues cr_live_ keys, stores a hash and returns the raw key at creation. A key belongs to one workspace. Supported scope families cover leads, campaigns and analytics; a key is not an unrestricted substitute for a browser session.

Work through the procedure

1. Create a key for the intended workspace with only the required scopes.
2. Store the raw key in the consumer’s protected server-side configuration.
3. Begin with a read-only request to a supported data route.
4. Inspect status and workspace data before enabling any writes.
5. Keep an owner and revocation plan for each consumer.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Illustrative HTTP request; replace the placeholder through protected configuration:
GET /api/leads HTTP/1.1
Host: zintara.io
Authorization: Bearer cr_live_REDACTED
Required scope for this read: leads:read

Read the result

An invalid or revoked key is an authentication problem. A valid key without the required route scope is an authorization problem. Do not respond to either by granting every scope without checking the consumer’s purpose.

Check before moving on

1. Confirm returned records belong to the intended workspace.
2. Keep keys out of browser bundles, URLs and screenshots.

Limits and next action

API keys do not authorize every application route, including account administration. The example is a request shape, not a live credential; verify deployed behavior before building a write integration.

Source: Zintara product context