Customer identity tokens (support_token)

Mint short-lived JWTs so your signed-in users can view and reply to their tickets without an AnswerRidge login.

Customer identity tokens (support_token)

A support_token is a short-lived JWT that proves an end user's identity to the ticket portal API and embeds. Your backend mints one for the signed-in user; the browser then talks to AnswerRidge directly, scoped to that user's tickets — no AnswerRidge account needed.

Mint a token (recommended)

Call POST /v1/customer-token from your backend with your API key:

curl -X POST "https://fbyeoijchofxayzhozwy.supabase.co/functions/v1/public-api-v1/v1/customer-token" \
  -H "x-api-key: ar_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "email": "jane@example.com", "name": "Jane Doe", "expires_in_sec": 3600 }'
{
  "data": {
    "token": "eyJhbGciOi…",
    "expires_at": "2026-09-26T13:00:00Z",
    "expires_in_sec": 3600
  }
}

expires_in_sec defaults to 3600 (min 60, max 86400).

Use the token

  • Ticket portal API — Authorization: Bearer <token> on ticket-portal-api endpoints (GET /tickets, GET /tickets/:id, POST /tickets/:id/reply). All responses are scoped to the token's email.
  • Ticket portal embed — pass ?support_token=<token> to /embed/tickets or the ticket-loader.js data-support-token attribute.

Roll your own (advanced)

The token is a plain HS256 JWT signed with your tenant's customer_auth_secret (Admin → Developer Portal). Payload:

{
  "tenant_id": "<your tenant uuid>",
  "email": "jane@example.com",
  "name": "Jane Doe",        // optional
  "iat": 1727350000,
  "exp": 1727353600           // seconds
}
// Node.js
import jwt from "jsonwebtoken";
const token = jwt.sign(
  { tenant_id: TENANT_ID, email: user.email, name: user.name },
  process.env.ANSWERRIDGE_CUSTOMER_AUTH_SECRET,
  { algorithm: "HS256", expiresIn: "1h" },
);

Security rules

  • Never mint tokens in the browser or ship customer_auth_secret / your API key to the client — always sign server-side.
  • Keep expires_in_sec short; mint a fresh token per page load/session.
  • The token grants read + reply on all tickets for that email — mint it only for users you have already authenticated.
  • Header mode (x-customer-email alone) exists for trusted server-side proxying; prefer tokens anywhere a client could set headers itself.