QR Code Generator REST API — Batch and Analytics

API access is on the Max plan at $20/mo. No per-request fees, no per-code fees. Rate limit is 100 requests per minute per API key, with batch creation up to 100 codes per call — so the effective ceiling is ~10,000 new codes per minute per key. If your workflow needs more, contact us and we'll talk about a custom rate-limit tier.

Full CRUD on QR codes plus analytics: create (single or batch up to 100), read (list with cursor pagination, get individual), update (repoint dynamic codes, rename, toggle active), delete (soft delete with 30-day undo), and scan analytics broken down by date, country, device, and referrer. Plus API-key management endpoints for rotation.

Bearer token auth. Include Authorization: Bearer ezqr_your_key in every request. Keys are generated from your dashboard at Settings → API Keys and are scoped to a single EZQR account. Per-environment scopes let you restrict a staging key to staging codes; production keys can be flagged as read-only or write-only.

The create endpoint returns the QR record with asset URLs for the rendered PNG, SVG, and PDF — fetch the image at the URL when you need it, or pre-cache the URL string in your database. The API itself doesn't stream binary images on the create call; this keeps the response payload small and lets you cache images at your CDN edge instead of EZQR's.

Static codes (created without a `target_url`) survive forever — the content is encoded into the QR pattern, no server dependency. Dynamic codes (created with a `target_url`) route through EZQR's redirect and need an active subscription. Pick the right tool: static for permanent destinations (asset tags, packaging), dynamic for anything you might need to repoint.

An API key from your dashboard and the ability to send an HTTP POST. That is the whole setup. Keys are scoped to your account, so treat one like a password and keep it server-side rather than in client code.

Yes. Static generation returns the image without persisting anything, which suits high-volume one-off rendering. Dynamic codes are stored by definition, because something has to hold your redirect. Choose per call, not per account.

PNG, SVG and PDF. Request SVG for anything heading to print or into a layout tool, PNG for screens and email. The response is the file itself, so you pipe it straight into your own storage without a second round trip.

Yes, and this is the call most integrations actually need. Your codes are already printed; the destination changes. One PATCH against the code ID repoints it. Every printed copy follows immediately.

Yes. Scan counts, timestamps and coarse location come back per code, so you pull them into your own dashboard rather than living in ours. That is the point of integrating. Otherwise the web app does the job.

100 requests per minute per API key. Every response includes X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, so your retry logic reads the reset time and backs off precisely. A 429 response carries a Retry-After header in seconds. Batch endpoints count as one request no matter how many codes are in the batch. Use them aggressively.

Your three oldest dynamic codes keep resolving and the rest pause until you resubscribe. Nothing is deleted. That matters most for API users, because you are the ones with codes printed at volume on stock you cannot recall.

Yes. Generation responses carry a validation result covering contrast ratio and a decode test, so your pipeline rejects an unreadable code before it reaches a printer. Wire that check into your build. Catching a failed code in CI costs nothing; catching it on a pallet of labels costs a reprint.