Two vendors both advertise a QR code API. One takes a string in a request and returns a PNG. The other creates a record on its servers, hands you a short URL to encode, counts every scan against it, and lets you change where it points next quarter. Same phrase on the marketing page, different products, different failure modes, different things to negotiate.
Two different products share one name
Image generation APIs are stateless. You pass content, you get an image back. Nothing persists on the vendor side, nothing is tracked, and if the vendor goes away your already-generated codes keep working, because a static code carries its destination inside the pattern.
Managed dynamic APIs are stateful. The vendor mints a code, hosts the redirect, records scans, and exposes a call to change the destination later. Everything you printed depends on that service resolving requests, on their infrastructure, for the life of the print.
goQR.me illustrates the split inside one company: it publishes a documented free QR API alongside its generator, while dynamic codes and analytics live in a separate paid product. Reading any vendor's docs with that distinction in mind saves a lot of confusion, because "QR API" in a headline can mean either thing. If you need the destination editable after shipping, an image endpoint will never give you that, and you want dynamic codes with a managed redirect.
Output formats and vector
Ask three things about output: which raster formats are supported, whether a vector format is available at all, and whether vector costs extra.
Vector matters more than developers expect, because the code usually ends up inside somebody's print file eventually. PNG covers screens and small labels. Large-format print wants SVG, EPS or PDF. Some vendors include vector free and others put it behind a paid tier, and that boundary shifts, so read the current API docs rather than any blog post about them, including this one.
Also check what the API lets you control: quiet zone, error correction level, module size, and foreground and background colors. An endpoint that returns a fixed-size PNG with no margin control will fight your layout later, and error correction level is not a cosmetic setting when the code is going on curved packaging.
Rate limits and batching
Every generation API has a ceiling. What differs is the behavior at that ceiling: a 429 with a retry hint, a silent throttle, a hard block, or an overage charge. Find the answer in the vendor's current documentation and write your client against the specific behavior rather than assuming a generic one.
Batching matters at volume. Minting ten thousand codes one HTTP request at a time is slow and fragile. Ask whether a batch endpoint exists, whether it is asynchronous with a job ID you poll, and how partial failures are reported. If a batch of five thousand returns 4,998 successes, you need to know which two failed and be able to retry only those. Our own bulk generator exists because that workflow is common enough to deserve a UI; through an API the same questions apply, just with your own retry logic.
Authentication, and what a key can do
Look at three properties of the auth model.
- Key scope. Can you issue a key that only renders images, separate from one that can edit destinations? A key able to repoint every live code is a different risk class from one that can only draw.
- Rotation. Can you roll a key without downtime, and does the old key get a grace window?
- Transport. Keys in query strings end up in server logs, proxies and browser history. Header-based auth is the safer default, and if a vendor only supports query-string keys, treat the generated URLs as secrets and keep them out of shared logs.
Per-environment keys are worth asking about too. Staging traffic contaminating production scan analytics is a common, boring, expensive mistake.
Storage: can you retrieve a code you generated last year
Teams forget this one. For stateless image APIs the answer is usually no: the image existed in the response and nothing was kept. That is often a privacy property rather than a gap, but it means your system is the system of record, and you have to store the content and the render parameters yourself to reproduce a code exactly.
For managed platforms, ask whether you can list codes, filter them, and export the inventory with destinations and creation dates included. An API that creates codes but offers no list endpoint leaves you unable to audit your own estate, which becomes a real problem the first time someone asks which codes point at a page you just deleted. That work is painful enough by hand, as finding dead codes shows.
Idempotency and retried webhooks
Two related problems, one on each side of the wire.
On the write side: if your create call times out, did the code get created? Without an idempotency key, retrying produces duplicates, and duplicates on a per-code-metered plan cost money and pollute reporting. Check whether the vendor accepts a client-supplied idempotency key on create, and how long it deduplicates for. If it does not, you need your own guard: a deterministic local ID, a lookup before retry, and a reconciliation job.
On the read side: if the platform sends webhooks for scan events, assume they will arrive more than once and occasionally out of order. Give every event a stable ID, store the IDs you have processed, and make handlers safe to run twice. Check whether webhooks are signed, and verify the signature instead of trusting the payload. If you are wiring scans into other systems, automation through an API or Zapier inherits the same requirement at the far end.
Uptime, and the license you are actually buying
Two items left, and both are contractual rather than technical.
Uptime changes meaning depending on where the API sits. Call it once at build time to render an image and an outage is an inconvenience you retry through. Put the vendor's redirect in the scan path of printed material and their downtime becomes your downtime, in public, in front of a customer holding a phone. Ask for a published status page, an incident history, and whether an SLA exists at your tier. Ask about the redirect infrastructure separately from the API, because they are often different systems with different reliability characteristics.
Licensing is the other. Confirm that generated codes may be used commercially and in print, that no attribution is required, and that the permission survives your subscription ending for codes already produced. Some vendors state this plainly: goQR.me's generator page says its codes are free of charge with commercial and print usage allowed. Others say nothing at all, which is not the same as yes.
One practical test before you commit. Encode your longest realistic payload through each candidate API and scan the result at your smallest print size. Payload length drives module count, and how much data a code can hold often decides whether your URLs need shortening before they need an API at all.
Then open both vendors' current API docs side by side and write down four things for each: stateless or managed, vector or not, batch or not, and whether the redirect has its own status page.
