Bulk QR Code API: Generate at Scale

"Bulk QR code API" gets searched by two groups with genuinely different problems, and most content on the topic blurs them.

Group one needs static codes at volume. Ten thousand product SKUs, a serial number per unit, an asset tag per machine. Each code carries distinct fixed data and never needs to change. This is a pure encoding problem and it is straightforward to solve in your own backend with an open-source library — no vendor, no API, no per-code cost.

Group two needs dynamic codes at volume. A tracked, editable code per store, per dealer, per campaign, where the destination must be changeable later and every scan must be attributable. This genuinely requires a platform, because the redirect and the analytics have to live on a server somewhere.

The two have almost nothing in common operationally. This guide covers both, and states plainly what SMLLR's own API does — which is reporting, not generation.

For group one, the entire problem is a loop over a data source. A CSV of SKUs in, a folder of images out.

import csv, qrcode

with open('skus.csv', newline='') as f:
    for row in csv.DictReader(f):
        payload = f"https://example.in/p/{row['sku']}"
        img = qrcode.make(payload)
        img.save(f"out/{row['sku']}.png")

Things worth getting right at volume that a naive loop misses:

• Export vector, not raster. Generate SVG or PDF so the same file works on a label, a carton and a banner without regeneration. Our file formats guide covers the trade-offs.
• Pin the error correction level explicitly. Do not rely on library defaults across a 10,000-code run — set Q for print, or H if a logo is involved.
• Keep payloads short and uniform. A consistent short URL pattern keeps every code at the same QR version, which means uniform module size and a predictable print size across the whole batch. Mixed-length payloads produce visibly inconsistent codes.
• Validate a sample. Decode a random sample of generated files programmatically and confirm the payload round-trips before sending 10,000 codes to a printer.

Our API-first QR generation guide covers the architecture patterns — queueing, idempotency, storage — for running this as a service rather than a script.

Group two's requirement is different in kind, not degree. A dynamic code's printed pattern encodes a short redirect link that must resolve on a live server — so generating one is not an encoding operation, it is a record creation operation. Something has to store the mapping, serve the redirect, log the scan, and let you edit the destination later.

That is why "just generate them with a library" does not work here: a library can draw the pattern, but there is nothing behind it. The tracking, the editability and the attribution all come from the platform, not the image.

It is also why bulk creation of dynamic codes is a meaningfully harder product feature than bulk static generation. Every code is a row with a lifecycle — it can expire, be deactivated, be reassigned to a campaign, accumulate scans. Creating ten thousand of them programmatically raises real questions about quotas, ownership and cleanup that a static generation script never has to answer.

Stated without hedging, because this is the question the search is really asking.

SMLLR's public REST API is read-only reporting. It exposes seven GET endpoints:

• GET /summary — account-wide scan summary for a period
• GET /qrs — paginated list of your QR codes
• GET /qr/:id — analytics for one QR code
• GET /campaigns — paginated campaign list
• GET /campaign/:id — analytics for one campaign
• GET /clients — paginated agency client list
• GET /client/:id — analytics for one agency client

It is available on the Premium plan (₹14,999/month), authenticated with an API key, and rate-limited to 60 requests per minute per key — keyed by the authenticated account rather than by IP, so integrators calling from shared infrastructure do not share a bucket. Responses come in a versioned envelope with cursor-based pagination.

There is no POST, PATCH or DELETE endpoint. The API cannot create a QR code, edit a destination, or delete anything. It also never returns Lead Hub contact data — no names, emails, phone numbers or consent records — by design.

The @smllr/mcp-server MCP server wraps the same seven endpoints as tools an AI agent can call, with the same Premium requirement and the same rate limit, because it calls the same API. Our REST API and MCP server explainer covers the response shapes.

This distinction matters and is worth being precise about, because the two are routinely conflated in QR platform marketing.

Bulk download takes QR codes that already exist in your account and exports them together as a print-ready set. SMLLR supports this from the Basic plan (₹1,999/month) upward, across five formats — PNG, JPG, SVG, PDF and EPS — so a whole campaign's codes can be re-exported in whatever format a specific print run needs.

Bulk generation creates many new codes at once from a list or spreadsheet. SMLLR does not currently offer this on its self-serve plans, and the honest position is that codes are created individually in the dashboard.

So the practical answer for a SMLLR customer needing many dynamic codes today is: create them in the dashboard, then bulk download the set in the format your printer wants. That is genuinely workable for dozens or low hundreds of codes — a code per store, per dealer, per campaign placement — and genuinely painful for ten thousand. If your requirement is ten thousand dynamic codes, that is worth raising with us directly rather than assuming a workaround. Our batch QR generation guide covers the current workflow.

Matching requirement to approach:

• Many static codes, fixed data, no tracking needed (SKU labels, serial numbers, asset tags): generate in your own backend with an open-source library. Fastest, cheapest, no dependency on anyone.
• Many static codes, but you want scan data: you cannot have both from a static code. Either accept no analytics, or move to dynamic codes and accept the creation overhead.
• Dozens to low hundreds of dynamic codes (one per store, dealer, placement, campaign): create them in the SMLLR dashboard, group them under a campaign, and bulk download the set for print. This is the common case and it works well.
• Thousands of dynamic codes: this is a real requirement that current self-serve tooling does not serve well. Talk to us about it rather than building a fragile workaround.
• Programmatic monitoring of many existing codes: this is exactly what the read-only API is for. Poll GET /qrs with cursor pagination and pull per-code detail where you need it — reporting dashboards, client-facing portals, automated alerts.

Create your QR code on SMLLR to start, and use the read-only API on Premium when you need to report on them programmatically.

Whichever route you take, a few decisions get expensive to reverse once codes are in the field:

• Decide static vs dynamic first. This is the only genuinely irreversible choice. A static code's data is in the pattern forever; converting later means reprinting everything.
• Fix a URL pattern and keep it. A consistent, short, versioned path (/p/{sku} rather than a query-string mess) keeps payloads uniform and gives you room to change what the path serves without changing the codes.
• Keep payload length uniform. Mixed payload lengths across a batch produce codes at different QR versions, which look inconsistent and print at inconsistent minimum sizes.
• Record which code went where. The most common regret at scale is a set of ten thousand codes with no record of which carton, store or batch each one was applied to — which makes the scan data uninterpretable later.
• Test a physical proof from the actual print run, not from the digital file. A code that decodes perfectly on screen can fail on the substrate.