Overview
Client Tokens allow you to call Limitry APIs directly from browsers and mobile apps without exposing your API key. They are short-lived, scoped tokens created by your backend.Client tokens use the
/client API endpoints, which are separate from the server-side /v1 endpoints.How It Works
- User visits your app — Your frontend needs to check usage or display quota information
- Your backend creates a token — Using your API key, call
POST /v1/client-tokenswith publicMetadata and serverContext - Token sent to browser — Your backend returns the token to the frontend
- Browser calls Client API — Use the token to call
/client/limits/checkor/client/events/summary
Creating Client Tokens
Create tokens from your backend using your API key:Payload: publicMetadata and serverContext
Tokens support two payloads:| Type | Description | Accessible To |
|---|---|---|
publicMetadata | Public data | Client (via GET /client/token) and handlers |
serverContext | Private data | Handlers only — never exposed to client |
publicMetadata) — Use for data the client needs to see:
| Field | Description |
|---|---|
customerId | Required. The customer to check usage for |
plan | Customer’s subscription tier (for UI display) |
serverContext) — Use for sensitive server-side data:
| Field | Description |
|---|---|
internalId | Internal database ID |
creditLimit | Credit limit (for enforcement) |
permissions | Detailed permission flags |
Using Client Tokens
In the Browser
Once you have a token, use it to call the Client API:Displaying Usage to Users
A common use case is showing users their current usage:With the Client SDK
Client API Endpoints
Client tokens can only access these endpoints:| Endpoint | Description |
|---|---|
GET /client/token | Retrieve the token (projectId + publicMetadata) |
POST /client/limits/check | Check limits for the customer |
POST /client/events/record | Record an event |
GET /client/events/summary | Get events summary for the customer |
Client tokens cannot access management endpoints like creating limits, viewing other customers, or modifying meters.
Token Lifecycle
Expiration
Client tokens expire after the specified duration (default: 1 hour). When a token expires, the client receives a401 Unauthorized error and should request a new token from your backend.
Revocation
You can revoke a token before it expires:Best Practices
Keep tokens short-lived
Keep tokens short-lived
Use the default 1-hour expiration or shorter. This limits the window if a token is compromised.
Create tokens on-demand
Create tokens on-demand
Don’t pre-generate tokens. Create them when the user needs to check usage or limits.
Always include customerId
Always include customerId
The
customerId in context determines whose usage is returned. Always set this to the authenticated user’s customer ID.Validate users first
Validate users first
Always authenticate users on your backend before creating a client token for them.
Security Model
| Aspect | API Key | Client Token |
|---|---|---|
| Where to use | Server only | Browser/mobile |
| Lifespan | Until revoked | Short-lived (hours) |
| Permissions | Full project access | Client API only |
| Created by | Dashboard | Your backend via API |
| Contains | Project ID | Project ID + customerId |