The QRCDN API

Mint a key, create a code, print it, then change where it points. Everything below is copy-pasteable.

1. 1. Mint a key

   Create one from the Studio: /api-keys → New key. It looks like qrcdn_live_… and is shown in full exactly once, so copy it somewhere safe. Keys are owner-scoped: yours can only see and change codes you created.

2. 2. Create a code

   POST a name and a destination. QRCDN assigns the slug, and the code is live immediately.

   Request

   curl -X POST https://www.qrcdn.com/api/v1/codes \
     -H "Authorization: Bearer qrcdn_live_…" \
     -H "Content-Type: application/json" \
     -d '{"name": "Launch poster", "destination": "https://example.com/launch"}'

   Response

   // 201 Created
   {
     "slug": "K4RN9WD",
     "name": "Launch poster",
     "destination": "https://example.com/launch",
     "status": "active",
     "scanCount": 0,
     "expiresAt": null,
     "passwordProtected": false,
     "url": "https://qrcdn.com/K4RN9WD",
     "createdAt": "2026-07-23T09:14:02.000Z"
   }

   Full reference: POST /codes

3. 3. Print it

   The response's url is the code's permanent address. Render the QR from the Studio or your own stack, then print it on anything.

4. 4. Scan it

   A scan never reaches your destination directly. It hits QRCDN's redirect layer first, which looks up where the code currently points and sends the visitor on:

   GET qrcdn.com/<slug> → 302 · cache-control: no-store → your destination

5. 5. Repoint it

   PATCH the same slug with a new destination. Nothing about the printed code changes.

   Request

   curl -X PATCH https://www.qrcdn.com/api/v1/codes/K4RN9WD \
     -H "Authorization: Bearer qrcdn_live_…" \
     -H "Content-Type: application/json" \
     -d '{"destination": "https://example.com/launch-v2"}'

   Response

   {
     "slug": "K4RN9WD",
     "destination": "https://example.com/launch-v2",
     "status": "active",
     "expiresAt": null
   }

   Full reference: PATCH /codes/{slug}

   Scan the same print again. New destination, same code. That is the whole product.

Every request carries a bearer token in the Authorization header. Mint and revoke keys from /api-keys; API access is a Pro plan feature. Keys look like qrcdn_live_… and are shown in full only once, at creation.

curl https://www.qrcdn.com/api/v1/codes \
  -H "Authorization: Bearer qrcdn_live_…"

A key is owner-scoped: every request only ever reads or changes codes its own owner created. There is no cross-account visibility, not even to confirm whether a given slug exists at all.

A missing or malformed header, a malformed key, and an unknown or revoked key all return the same 401 shape (only the message text differs), so probing a key can never confirm whether it once existed:

// 401 Unauthorized
{ "error": "unauthorized", "message": "Invalid API key." }

A key that authenticates fine but whose plan does not include the API gets a 403 instead:

// 403 Forbidden
{ "error": "api_not_available", "message": "The API is available on the Pro plan." }

• A code can carry an expiry, a password, or both: each is independent and optional.
• Expiry is settable via the API today (expiresAt, PATCH above). Password protection is Studio-only in this release: a plaintext password in an API request body needs its own transport and logging review before it's exposed here, so it isn't yet.
• A password-protected code's scan lands on an unlock page; a correct password forwards the visitor to the destination.
• An expired code's scan serves the same unavailable page a paused code does, not the destination. Clearing the expiry brings it straight back: your code never dies.

Every non-2xx response is { "error": "<code>", "message": "<string>" }. For 422s the message is often the same short code as the error field (e.g. invalid_destination, slug_taken); for other statuses it is a human-readable sentence. A request body that is not valid JSON also 422s as invalid_request, before any field is even looked at.

Every endpoint above can also return these, regardless of its own errors table:

• The API is available on the Pro plan: up to 10,000 accepted requests per key per UTC calendar month. The request that would push you over the cap returns 429 quota_exceeded instead of running.
• The quota resets at the start of each UTC month. Any authenticated request counts toward it, even one that goes on to fail validation (422) or address a code you do not own (404): the count happens at the authentication layer, before your request is evaluated.
• There is no burst-level (per-second) rate limiting yet: the monthly cap above is the only ceiling today. Burst limiting arrives with general launch.