Skip to main content
Portal tokens are short-lived, operation-scoped credentials meant to be embedded in customer-facing surfaces — typically a dashboard you host where your own customers check their Sly usage, invoices, or transfer history. Unlike API keys (which grant broad tenant access) and agent tokens (which act as an agent), portal tokens are read-oriented and scoped to specific operations. They’re safe to ship to a browser.

Token format

Common scopes

Scopes are combined with a resource filter — e.g. “read usage for customer_id = cust_abc” — so one portal token cannot see another customer’s data.

Create a portal token

Your backend mints the token on demand, typically when a customer loads their dashboard:
Response:
Ship the token to the browser; your customer’s session uses it directly against the Sly API.

Use a portal token

From the browser (or anywhere):
Calls outside the granted scopes return 403 Forbidden. Calls after expires_at return 401.

Revoke a token

Revocation is instant (tokens aren’t cached like API keys).

Typical integration pattern

Your backend never exposes pk_live_* to the browser. The portal token is scoped, expiring, and customer-bound.

Security practices

  • Short TTLs. Default to 1 hour. Re-mint on page load if needed.
  • One customer_reference per token. Never mint a token that spans customers.
  • Read-only scopes by default. Write operations should flow through your backend.
  • Log every portal_token mint for audit. Include the requesting customer’s identity.