SMLLR REST API for Developers: A Straight Answer on What It Does

If you're evaluating SMLLR for a SaaS platform, e-commerce company, or logistics firm that needs to generate thousands of unique dynamic codes programmatically, it's worth knowing upfront: SMLLR's public API does not create or edit QR codes. It's a read-only reporting API — built for pulling scan analytics for your account, individual QR codes, campaigns, and clients into your own systems. QR code creation and destination-URL editing happen through the SMLLR dashboard. This guide covers exactly what the API does cover, so you can decide if it fits your integration before you build against it.

Authentication is a static, high-entropy API key (format smllr_live_...), generated from Settings → API in the dashboard — available on the Premium plan only, with no free or lower-tier access. Send it as the x-api-key header, or as a Bearer token in Authorization. There's no OAuth2 flow, no scoped/restricted keys, and no token expiry to manage — if a key is compromised, regenerate it from Settings and the old one stops working immediately.

Every endpoint is a GET request returning a { success, data } JSON envelope, with period (7d/30d/90d/all) accepted where relevant. List endpoints (/qrs, /campaigns, /clients) are cursor-paginated rather than offset-paginated.

To be direct about the gaps, since these are the features developers most often ask for: there is no endpoint to create or update a QR code's destination URL — that's dashboard-only. There is no bulk/batch creation endpoint on any current self-serve plan (a CSV bulk-create feature exists only for a small number of grandfathered legacy accounts, not for new customers on any current tier). If real-time reaction to a scan is what you need, that's not the REST API's job — use Webhooks (Pro plan and above) instead: register a URL or a Slack channel and SMLLR pushes a signed payload the instant it happens, no polling required.

The API is rate-limited to 60 requests per minute per API key — a flat limit, not something that scales up on higher plans. It's tracked per key, so it isn't shared with unrelated traffic from the same office network or NAT'd infrastructure. For a scheduled sync (e.g. refreshing a BI dashboard every few minutes) this is generous; for anything approaching real-time polling, you'll want to space out requests and back off on a 429 rather than retry immediately.

Despite the gaps above, the reporting API covers a genuinely useful set of real-world integrations: feeding QR/campaign/client scan data into an internal BI tool or Pandas pipeline, building a lightweight custom client-reporting view for an agency (as an alternative to SMLLR's own hosted client dashboard), or scheduling a periodic export into a data warehouse. If your need is 'get scan data out of SMLLR programmatically,' it fits well. If your need is 'create and manage QR codes without touching the dashboard,' it doesn't cover that today.