Skip to main content
Every call to POST /generate is authenticated with an API key, sent as a bearer token. 
Authorization: Bearer tipar_live_<32 characters>
A key looks like tipar_live_aB3dE... — the tipar_live_ prefix followed by 32 random characters. There is no separate API secret or signature; the key alone authenticates the request.

​
Creating a key

API keys are managed from the dashboard, not from the API:
1

Sign in

app.tipar.dev signs you in with a passwordless magic link sent to your email.
2

Create a key

Under API keys, give the key a name (something that says where it’s used — prod-billing-worker, staging) and create it.
3

Copy it once

The full key is shown only at creation. Tipar stores a SHA-256 hash, never the key itself — so it can’t show it to you again and can’t recover it. Copy it now into your secrets store.
The name and a four-character suffix (e.g. …aB3d) are kept so you can recognise a key in the dashboard. The suffix is not enough to use the key — only the value you copied at creation is.

​
Using a key

Send it as a bearer token on every request: 
curl https://api.tipar.dev/generate \
  -H "Authorization: Bearer $TIPAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d @request.json --output out.pdf

​
When authentication fails

A missing, malformed, or revoked key returns 401 Unauthorized with a WWW-Authenticate: Bearer header. The body is a Problem Details document. The request never reaches the renderer, so no quota or rate limit is consumed.
SituationResult
No Authorization header401 Unauthorized
Header isn’t Bearer <key>401 Unauthorized
Key doesn’t exist or was revoked401 Unauthorized
Valid key, but monthly quota reached402 Payment Required — see quotas
Tipar checks the key’s prefix before any database lookup, so malformed tokens are rejected cheaply. That’s an implementation detail, not something you need to handle — just send a valid tipar_live_ key.

​
Revoking and rotating

Revoke a key from the dashboard at any time. Revocation takes effect within seconds across the service; the next request with that key gets 401. To rotate without downtime:
1

Create the replacement

Mint a new key and deploy it to your environment alongside the old one.
2

Cut over

Switch traffic to the new key and confirm requests still return 200.
3

Revoke the old key

Once nothing uses it, revoke the old key from the dashboard.

​
Good practice

Keep keys server-side

Use a key only from a backend you control. Never embed it in a browser, a mobile app, or anything a user can inspect.

Store in env / secrets

Inject the key through environment variables or a secrets manager. Keep it out of source control and CI logs.

One key per use

Separate keys for prod, staging, and each service. Revoking one then never affects the others.

Rotate on exposure

If a key might have leaked, revoke it immediately and mint a replacement. There’s no limit on how many keys you can hold.