SDK Authorization

The Client Access Token endpoint is how you authenticate an end user's access to zerohash SDK modules. Your platform authenticates to zerohash with its own server-side credentials, requests a token scoped to a specific user and set of SDK experiences, and hands that token to the user's client to initialize the SDK. In short: this is the credential that lets a given user run a given zerohash SDK flow — and nothing more.

For engineers, the mental model is a short-lived, server-minted key. Your backend never exposes its long-lived HMAC credentials to the browser or app; instead it calls this endpoint to mint a scoped JWT on the user's behalf, and the front-end SDK uses that JWT to do its work. The permissions you request are what determine which SDK modules the token can open.

Minting a token — POST /client_auth_token

Generates a temporary JWT for an end user, scoped to the SDK experiences you request.

Used for invoking the follow SDK modules;

Your backend authenticates the request with the standard HMAC headers, and zerohash returns the client access token for you to pass to the SDK.

📘
Mint server-side, scope tightly
Request only the permissions a given flow actually needs, and mint the token on your backend — the endpoint is authenticated with your platform's HMAC credentials, which should never reach the client. The user only ever sees the resulting JWT.

Revoking a token — POST /revoke_auth_token

Invalidates a client access token that was previously issued, preventing it from being used to initialize any further SDK modules. You pass the token to revoke (a well-formed JWT), and your platform authenticates with its own HMAC credentials rather than the token itself.

Reach for this whenever a token should no longer be trusted — routine rotation, a user session ending, or a suspected credential compromise — to cut off access ahead of the token's natural expiry.