Authentication
Authenticate Client Links API requests with an agency key or a location secret key, passed as a bearer token.
Authentication
The Client Links API is client-scoped and uses client keys — not an admin session. Two key types are accepted:
| Key | Prefix | Access | Scope |
|---|---|---|---|
| Agency key | ak_ | Read-write | An agency; must name a specific client (location) per request |
| Location secret key | sk_ | Read-only | A single client (location), resolved from the key itself |
Pass the key as a bearer token on every request.
Bearer token. Format: Bearer ak_... or Bearer sk_....
A key must be supplied via the Authorization header above. Anything that is not prefixed with ak_ or sk_ is rejected with 401.
Selecting a client with an agency key
An agency key spans multiple clients, so every request made with an ak_ key must name the target client (location). Supply it as a query parameter or header — omitting it returns 401.
Target client (location) id. Required for agency keys. Verified against the
agency; a location not linked to the agency returns 403.
Alternative to the location_id query parameter for agency keys.
Location secret keys (sk_) already resolve to exactly one client, so location_id is ignored for them.
Examples
curl "https://mythic-analytics.gulp.workers.dev/client/v1/links?location_id=acme-retail" \
-H "Authorization: Bearer ak_your_agency_key"
curl "https://mythic-analytics.gulp.workers.dev/client/v1/links" \
-H "Authorization: Bearer ak_your_agency_key" \
-H "X-Location-Id: acme-retail"
curl "https://mythic-analytics.gulp.workers.dev/client/v1/links" \
-H "Authorization: Bearer sk_your_location_secret_key"
Treat both key types as secrets. The agency key is read-write across every
client in the agency — never expose it in client-side code, public
repositories, or logs. Prefer the read-only sk_ key for browser or
untrusted contexts.