QR Code API Tutorial: Create & Track Codes in Code

How a QR code API workflow works

A typical QR code API workflow has three parts. First, you send an authenticated request with your API key, usually in an Authorization header as a Bearer token. Second, you POST a payload to create a code, often by defining a destination URL plus optional metadata like a campaign name, tags, or expiration rules. Third, you query analytics endpoints later to see how many scans happened and where they came from.

For most real-world use cases, you want a dynamic QR code rather than a static one. A static code directly stores the final destination, which means changing the landing page requires printing a new code. A dynamic code points to a short link you control, so the printed QR stays the same while you can update the destination and track every scan over time.

The practical pattern is simple: create the code once, store the returned ID and short URL in your database, render the QR image in your app or dashboard, and then poll or request analytics by that code ID or link ID. If you are using a platform like ScanIQ, this is the same developer flow behind editable QR destinations and built-in scan tracking.

Authenticate with a Bearer key

Most QR code APIs use HTTPS plus token-based authentication. After generating an API key in your account, send it in the Authorization header like this: Authorization: Bearer YOUR_API_KEY. Never hardcode production keys in frontend JavaScript, mobile binaries, or public repos. Keep them on the server side and load them from environment variables.

A minimal cURL test helps verify your auth before you build anything else. For example, a create request usually looks like: curl -X POST https://api.example.com/v1/qr-codes -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" -d '{"destination":"https://example.com/promo","type":"dynamic"}'. If the key is valid, you should get a 200 or 201 response with a JSON body containing the new code record.

If your request fails, start with the basics. A 401 usually means the key is missing, expired, malformed, or tied to the wrong environment. A 403 often means the key exists but lacks permission for that endpoint. Also confirm you are sending JSON correctly, because a bad Content-Type header or invalid payload can produce errors that look unrelated at first.

POST a request to create a dynamic QR code

The exact schema varies by provider, but the payload usually includes a destination URL and a flag or object that tells the API to make the code dynamic. Many APIs also accept optional fields such as title, slug, tags, campaign, custom domain, or style settings. Keep your first request minimal, then add extra fields only after the core flow is working.

A generic request body might look like this in JSON: {"type":"dynamic","destination":"https://example.com/spring-sale","name":"Spring Sale Poster","tags":["retail","poster"]}. In response, expect values such as an id, a managed short URL, timestamps, and one or more image URLs or raw QR content you can render yourself.

Here is the same idea in JavaScript using fetch: const res = await fetch('https://api.example.com/v1/qr-codes', { method: 'POST', headers: { 'Authorization': `Bearer ${process.env.API_KEY}`, 'Content-Type': 'application/json' }, body: JSON.stringify({ type: 'dynamic', destination: 'https://example.com/spring-sale', name: 'Spring Sale Poster' }) }); const data = await res.json(); Store data.id and data.shortUrl because you will need them later for updates and reporting.

If the API returns both a QR image URL and the underlying short link, save both. The image URL is useful for dashboards, PDFs, or print workflows. The short link matters because the dynamic behavior usually lives there: the QR resolves to the short link, and the short link redirects to the current destination you control.

Render, save, and update the destination later

Once the code is created, you typically either display a hosted PNG or SVG returned by the API, or you generate the image on your side from the returned short URL. SVG is usually the better choice for print because it scales cleanly. PNG is fine for web previews, emails, or quick exports where you know the target size.

The key benefit of a dynamic code is that the QR image does not need to change when the landing page changes. Instead of regenerating and reprinting the code, you send an update request to the API for that code ID or link ID. A generic PATCH might look like: PATCH /v1/qr-codes/{id} with a body such as {"destination":"https://example.com/new-page"}.

This is where developers save time in production. Imagine a restaurant menu, event poster, packaging insert, or support sticker already in the field. If the original page moves, the campaign changes, or you need to route scans by season or inventory, you update the destination in code and keep the printed QR live. That is the operational reason dynamic QR codes are usually the right default.

Read scan analytics from the API

Analytics endpoints usually let you fetch totals plus breakdowns over time. Common fields include total scans, unique scans, timestamped events, country or region, device type, browser, operating system, and referrer. Some APIs also support date filters, grouping by day or week, and pagination for raw event logs.

A typical request might be something like GET /v1/qr-codes/{id}/analytics?from=2026-07-01&to=2026-07-31&groupBy=day with the same Bearer header. The response often includes a summary object and an array of buckets. For example, you might get daily scan counts plus top countries and devices for that date range.

When you consume analytics in an app, decide early whether you need event-level data or only summaries. Dashboards often need totals and daily trends, while a data pipeline may need raw scan events for warehousing. Store only what you need, and be mindful of privacy, retention rules, and whether location data is approximate rather than exact GPS.

One practical pattern is to create the QR code during campaign setup, then fetch analytics on a schedule for reporting. If you are building internal tools, you can map scans back to campaign names or tags saved when the code was created. In products like ScanIQ, that same pattern powers reports on scan trends, location, devices, browsers, and referrers without changing the printed code.

Common implementation tips and next steps

Start with cURL or Postman before writing SDK wrappers. It is easier to debug auth headers, payload shape, and response fields when you can see the raw request. After that, wrap the API in a small service layer in your app so code creation, updates, and analytics fetching are handled in one place with retries and structured error logging.

Validate destination URLs before sending them to the API, and save the provider's returned IDs in your own database. Use idempotency keys if the API supports them, especially when code creation is triggered by webhooks or background jobs. That helps prevent duplicate QR records when a request times out and your app retries.

If you are following this QR code API tutorial as a first integration, your next steps are straightforward: verify Bearer auth, create one dynamic code, render the returned image or short link, update the destination once, and then call analytics for a test date range. Once that loop works end to end, you can add bulk creation, custom styling, campaign tagging, or dashboard reporting with confidence.

Keep reading