Authentication

Tupsara has two credential types. Which one you need depends on the endpoint.

Credential	Header	Where it works
API key	Authorization: Bearer pdf_live_...	/v1/pdf, /v1/templates (read + generate), /v1/usage
Clerk session token	Authorization: Bearer <session-jwt>	Everything — including /v1/api-keys, /v1/me, and creating/editing/deleting templates

Why isn’t an API key enough everywhere? Account-management actions — creating another API key, revoking one, creating or editing a template — always require a real signed-in session. An API key that could manage other API keys could mint itself a persistent replacement or revoke the real one if it ever leaked; keeping that a human-only action closes that hole. API keys are for the actions you’d want to automate (rendering PDFs, reading usage, browsing/using templates), not account changes.

A resource owned by someone else always looks like it doesn’t exist. A PDF job or template that belongs to a different account returns 404, not 403 — a response never confirms that something you don’t own exists.

Getting an API key

curl -X POST https://api.tupsara.com/v1/api-keys \
  -H "Authorization: Bearer <clerk-session-jwt>" \
  -H "Content-Type: application/json" \
  -d '{"name": "Production server"}'

{
  "id": "...",
  "prefix": "pdf_live_a1b2",
  "name": "Production server",
  "key": "pdf_live_a1b2c3d4e5f6...",
  "created_at": "2026-08-30T10:00:00Z",
  "last_used_at": null,
  "revoked_at": null
}

key is the only time the full value is ever returned. Afterwards, GET /v1/api-keys only shows the prefix.