Practical QR code uses for small business with Qrop

Two ways in: the dashboard and the API

Both paths produce identical output, the same custom SVG renderer, the same automatic error-correction upgrade when a logo's involved, the same colour-contrast guard rejecting combinations a phone camera would struggle to scan. The difference is entirely about who, or what, is doing the generating.

The dashboard is for a person deciding, in the moment, that a QR code needs to exist: pick a type, set the colours, download it. The API is for a piece of software deciding that, automatically, every time a condition is met, an order placed, a ticket sold, a product listed, without anyone opening a browser.

Example: a café builds its in-store QR pack in the dashboard

A small café needs three codes, total, to cover its entire in-store setup: one for the guest Wi-Fi, one vCard for the owner's business cards, and one linking to an online ordering page for a window sticker. All three fit comfortably inside the free registered allowance and none of it needs code.

1. Open the generator and select Wi-Fi as the data type. Enter the guest network's SSID and password, choose WPA as the encryption type, and Qrop checks the contrast of the chosen colours before letting the code be generated.
2. Switch to vCard, fill in the owner's name, phone, and the café's website, and download it as SVG so it stays sharp printed small on a business card.
3. Switch to URL, point it at the online ordering page, add the café's logo (error correction jumps to H automatically once a logo's in the centre slot), and choose a rounded module style to match the café's branding.
4. Download all three as PNG for print, at 1024px, comfortably above the resolution needed for a window sticker or table tent.

Example: an online store stamps a QR code on every order automatically

A boutique online store wants every order confirmation email to include a QR code linking to a live tracking page, with the store's logo composited in. That's not a job for the dashboard, it happens hundreds of times a month and needs to happen the instant an order is placed, so it's a single server-side call to /api/v1/generate wired into the checkout flow.

• The request sends the order's tracking URL as data, type: "url", and the store's logo as a base64 logoDataUrl so no external fetch is needed.
• The response comes back in well under 200ms warm, a base64-encoded PNG the server drops straight into the confirmation email template.
• Each call costs exactly 1 credit, drawn from the store's Starter plan allocation, no separate charge for the logo since the API's flat 1-credit rate already includes it.
• A minimal request body: { "data": "https://shop.example/track/ORD-4821", "type": "url", "format": "png", "resolution": 1024, "logoDataUrl": "data:image/png;base64,..." }

Example: a boutique batch-generates its whole product tag run

The same store, a few weeks later, needs QR codes for 40 new product tags landing in stock, each linking to its own product page. Calling /api/v1/generate 40 times in a loop would work, but /api/v1/generate/batch does it in one request: up to 25 items per call, one shared logo applied across the whole batch, so a single order run of 40 codes is two batch calls (25, then 15) rather than 40 separate ones.

A batch request lists each item's data and type individually, but the format, resolution, and logo are set once for the whole batch, which is exactly the shape a product-tag print run needs: same branding, same size, different destination URL per tag.

Response includes a results array with one entry per item and a single creditsConsumed total for the whole batch, so reconciling the charge against the print run is a one-line check, not 40.

Example: an events business issuing ticket codes as they sell

A small events business selling tickets to a single show doesn't know in advance how many codes it'll need, so generating them all upfront doesn't fit. Instead, each ticket code is generated the moment a ticket sells: the checkout handler calls /api/v1/generate with a unique per-ticket URL (a validation endpoint the door staff's scanner hits) as data, and the resulting PNG goes straight into the ticket-confirmation email.

This is the same pattern as the order-confirmation example, one API call per event, triggered by a real action, rather than a batch run. The choice between a single call and a batch call comes down to whether you know all the destinations at once (batch, for a print run) or whether they arrive one at a time over hours or days (single calls, for anything sold live).

Choosing between the dashboard and the API for your own workflow

• If a human is deciding, in the moment, that a code needs to exist, and it happens a handful of times a month, use the dashboard. There's no reason to write code for three Wi-Fi signs a year.
• If a code needs to exist every time something else happens (an order, a signup, a ticket sale, a new product listing) without anyone clicking a button, that's the API, regardless of how small the business is.
• If you know the full list of destinations upfront (a print run of product tags, a batch of event badges), use /api/v1/generate/batch and get up to 25 codes in one call instead of one request per item.
• If destinations arrive one at a time as real events happen (a live checkout, a ticket sale), use /api/v1/generate per event rather than trying to batch something that isn't actually batched in reality.

Getting an API key and making your first call

1. Register a free account at /register, only a name and email address required.
2. From the billing dashboard, subscribe to an API plan, Starter at R149/month for 3,000 included credits covers most small-business volume to start.
3. Open the API Keys tab and create a key. It's shown once, copy it immediately, Qrop stores only a hash and can't display it again.
4. Make a test call: POST to /api/v1/generate with Authorization: Bearer <your-key> and a JSON body specifying data, type, and format. The response is a base64 image you can drop straight into an <img> tag or save to a file.
5. Check /api/v1/usage any time to see the current period's credit consumption and how much of your monthly allocation is left before overage kicks in.

Frequently asked questions

Related guides