Authentication
Authenticate partner API requests with project-scoped server keys.
Every partner API operation requires a server API key. Send it as a Bearer token:
The SDK adds this header automatically when initialized with apiKey.
Create and protect a key#
An authorized project owner creates a key in the dashboard's Developers section. Choose only the campaigns and permissions the integration needs. The complete secret is shown once; store it in your server's secret manager or protected environment configuration.
Do not store keys in source control, browser storage, analytics payloads, screenshots, or support messages. Do not send a Slices server key to any other provider.
What a key authorizes#
A key is bound to a project and environment, with configured campaign and operation permissions. Knowing another campaign ID or reward ID does not grant access to that resource.
Use separate keys for unrelated integrations and environments. A read-only reporting integration should not be able to issue or cancel rewards. Permission labels are supplied by the deployed key-management interface; do not assume arbitrary scope strings are accepted.
An event or recipient in a JSON body cannot select another project, grant operator privileges, or authorize additional token spending.
API access and dashboard access are different#
Dashboard users sign in through the business authentication flow. Server API keys authorize the /v1 partner API. They do not authorize operator-only dashboard operations such as approving draft campaigns, sending transfers, or enabling a production profile.
Never copy a browser session cookie into a production server integration. Never place a partner API key in dashboard frontend state to make console actions work.
Authentication responses#
| HTTP status | Code | Meaning |
|---|---|---|
401 | UNAUTHENTICATED | A usable key was not supplied, or the key is invalid or revoked. |
403 | FORBIDDEN | The key is recognized but does not authorize the operation. |
404 | NOT_FOUND | The resource is unknown or outside the caller's accessible project scope. |
An idempotent replay still requires valid authorization. A revoked key cannot retrieve or replay an old instruction merely because that instruction was once accepted.
Rotate a key#
Create a replacement with the required minimum access. Update the backend secret, test an authorized read, and revoke the old key after confirming the integration has switched. Preserve the original idempotency keys for outstanding instructions during rotation.
Key rotation does not reset financial deduplication. Never generate replacement event IDs or fresh issuance keys simply because credentials changed.
Suspected exposure#
Revoke the exposed key, pause new issuance where appropriate, and review accepted and queued rewards. They can be cancelled; approved and sent rewards cannot be recalled through the cancellation API.
Include request IDs and affected reward IDs in incident reports. Never include the secret itself.
Related: Security, Idempotency, and Dashboard.