Authentication¶

Every request to the Pulse API is authenticated with an API key. There are no sessions or cookies to manage — you include your key on each call, and Pulse identifies your workspace from it.

The Authorization header¶

Send your API key as a Bearer token in the Authorization header on every request:

Authorization: Bearer <your-api-key>

A complete authenticated request looks like this:

curl https://api.azothedge.com/v1/schemas \
  -H "Authorization: Bearer <your-api-key>"

If the header is missing or the key is invalid, the API responds with 401 Unauthorized.

Keys are scoped to your workspace¶

Each API key belongs to exactly one workspace. Pulse uses the key to determine which workspace a request acts on, so:

• You never pass a workspace or tenant identifier yourself — the key carries that context.
• A key can only read and write data in its own workspace. Data from other workspaces is never visible, even if you reference it by id.

Read keys and editor keys¶

Access is role-based. The key you use determines what you're allowed to do:

• Read access can call read-only endpoints (for example, listing schemas or reading profiles).
• Editor access or higher is required for any write — sending data, creating schemas, linking identities, building audiences, and so on.

If you use a read-only key for a write request, Pulse responds with 403 Forbidden. Use an editor-or-higher key for those calls.

Keep your keys secret¶

An API key grants access to your workspace's data. Treat it like a password:

• Store keys in your application's secret manager, not in source you share.
• Never expose a key in client-side code, a public page, or a logged URL.
• Use separate keys for separate applications so you can revoke one without affecting the others.

Next steps¶