Dynamic QR code APIs: build vs buy, with working examples

The three layers of a dynamic QR system

1. Image generation — encoding a URL as a QR graphic. Commoditised: open-source libraries (segno, qrcode.js) and free APIs do this well.
2. The managed redirect — the short URL inside the code, resolving in milliseconds, re-pointable after printing, on a domain that won't disappear. This is real infrastructure: hot-path storage, custom domains with HTTPS, uptime.
3. The event pipeline — scan analytics (source, device, geo, bots filtered) and real-time delivery to your systems: webhooks, Slack, automation tools.

Build-vs-buy is really about layers 2 and 3. Layer 1 is a library import; layers 2 and 3 are an ops commitment — redirect uptime is forever, because the codes are printed.

Worked example: a dynamic QR in three calls

These run against the live xengo API (Pro plan; full spec at /v1/openapi.json).

1. Create the link (the thing the QR encodes)

curl -X POST https://api.neon.xengo.io/v1/links \
  -H "Authorization: Bearer $XENGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "destination": "https://acme.com/spring-offer",
    "code": "spring24",
    "tags": { "campaign": "spring" }
  }'

2. Fetch the QR as print-ready SVG

curl https://api.neon.xengo.io/v1/links/spring24/qr?scale=10 \
  -H "Authorization: Bearer $XENGO_API_KEY" > spring24.svg

3. Re-point it after printing (the "dynamic" part)

curl -X PATCH https://api.neon.xengo.io/v1/links/spring24 \
  -H "Authorization: Bearer $XENGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "destination": "https://acme.com/summer-offer" }'

The printed code never changes; every scan now lands on the new destination. Add a webhook channel and each scan also arrives as a signed JSON event — headers, payload and verification code are on the events page.

If you build it yourself

Honest checklist of what layer 2 + 3 actually involve:

• A redirect service you're happy to keep up for the printed life of every code (years), with hot-path reads and 302 (never 301) semantics so codes stay re-pointable.
• Custom domains with automated certificates, if codes should carry your brand.
• Scan capture that doesn't slow the redirect: queue-based, with device/geo enrichment and bot filtering if the numbers are meant to be honest.
• Delivery infrastructure if systems need to react: signing, retries, dead-letter queues, a delivery log.
• Abuse screening if anyone but you can create codes.

That's a real (and interesting) engineering project — it's roughly what we built. If it's core to your product, build it. If it's plumbing for your actual job, buy it from us or, honestly, from any of the platforms in our cited comparisons.