SMLLR Analytics API for Python: A Developer Guide

SMLLR's public API is a read-only reporting API, not a QR-generation API. It lets you pull scan analytics for your account, individual QR codes, campaigns, and (for agencies) clients as JSON — perfect for feeding a Python data pipeline, a Pandas notebook, or a Streamlit dashboard. Creating and editing QR codes — including changing a destination URL — is done through the SMLLR dashboard, not this API. This guide covers what the API can actually do and how to call it from Python.

Whether you're running a Django web app or a simple script to sync scan data into an internal dashboard, Python's clean syntax and library ecosystem make it a solid fit for consuming the SMLLR reporting API. This guide is for the developer pulling QR, campaign, and client analytics into a Python backend or notebook.

Authentication is a single static API key, not a JWT or OAuth2 flow — there's no token refresh to manage. Generate your key from Settings → API in the SMLLR dashboard (Premium plan required); it's shown once, so copy it immediately. Send it as the x-api-key header, or as a Bearer token in the Authorization header — either works.

The core endpoints return JSON scan analytics, paginated with a cursor for list responses. GET /summary gives account-wide totals; GET /qrs lists your QR codes (paginated); GET /qr/:id gives detailed scan analytics for one code — device breakdown, location data, and daily/hourly trends. All accept a period query param (7d, 30d, 90d, or all, defaulting to 30d).

For agencies and teams running multiple campaigns or managing multiple clients, the same pattern applies at the campaign and client level — useful for building a client-facing Python dashboard without re-deriving aggregation logic yourself.

Every endpoint returns a consistent { success, data } JSON envelope, which drops straight into a Pandas DataFrame — no scraping or CSV export needed. Because list endpoints (/qrs, /campaigns, /clients) are cursor-paginated, loop until pagination.hasMore is false to pull a full dataset rather than assuming everything fits on one page.

At 60 requests per minute per key, a Python script syncing a large account should paginate deliberately rather than firing requests in a tight loop — batch your calls, add a short delay between pages, and handle a 429 response by backing off rather than retrying immediately. For most dashboard-refresh use cases (pulling data every few minutes, not every few seconds), this limit is generous; if you need a higher ceiling for a high-volume integration, contact SMLLR support.