Rename or disable a QR code

Renaming a slug moves the path but keeps the source label; disabling a code never breaks the physical carrier.

A printed carrier can't be edited once it's out in the world — renaming or disabling a code in the panel only ever changes what happens after someone scans it, never whether the scan itself resolves.

curl -X PATCH https://app.tease.link/api/admin/qr/links.creator.com/3 \
  -H "Authorization: Bearer $TEASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "slug": "flyer-v2" }'

PATCH accepts any of title, slug, channel, design, preset, active — only the fields you send are changed.

Renaming the slug

The source attribution label is stamped once, at creation, from the original slug (qr for the main code, qr-<slug> for a named one) — and it never changes, including on rename. So:

The code's scan path moves to the new slug immediately.
Every stat already collected, and everything collected after the rename, stays on the same source label — the funnel history in Read a QR code's funnel doesn't split or reset.
The already-printed carrier still encodes the old path. A scan of it still redirects the visitor (nothing 404s) — but since no code matches that old slug any more, the visitor lands unlabelled instead of under the old code's source.

Renaming is safe for history, not for physical media already in circulation. If a carrier is still being scanned, either don't rename it — add a new code for the new placement instead — or accept that the old print stops carrying attribution the moment the rename takes effect.

Disabling instead of deleting

Set active: false rather than deleting a code whose printed carrier might still be scanned. Disabling immediately removes it from the set of codes the public scan path matches — a scan of a disabled (or deleted) code's path still redirects the visitor to the landing/page root, it just arrives unlabelled, exactly like the old path after a rename. Nothing a QR code can encode ever resolves to a 404.

Re-enabling (active: true) restores labelled attribution under the same source the code always had.

How to know it worked

GET /api/admin/qr/{domain} reflects the change within moments — mutations reset the public scan-path cache immediately, so there's no propagation delay to wait out. Scan the physical carrier to confirm the old printed path now behaves the way you expect (still redirects, unlabelled).

If it didn't work

400 slug_taken — another active code on this domain already owns that slug.
The rename "broke" reporting — it didn't; check whether you're comparing by slug (which changed) instead of by code id or source (which didn't).

What's next

Read a QR code's funnel — confirm the change didn't disturb the numbers.
Moving the whole domain instead of one code? A connected QR code blocks domain rotation by design — see Troubleshooting.