A QR & link API your backend will like.

Bearer-token auth, RFC 7807 errors, idempotency on every POST, signed webhooks, and an OpenAPI spec rendered at /docs. Built so 100+ products can integrate without operational friction.

1. Mint an API key

Open Settings → API keys, give it a name, pick scopes (e.g. links:write), and copy the secret once.

qrf_live_aB3kQ9m...

2. Authenticate

Send the key as a Bearer token. Per-key rate limits and IP allowlists are enforced server-side.

Authorization: Bearer qrf_live_aB3kQ9m...
Idempotency-Key: 8a72b9e0-...

3. Create a dynamic link

curl -X POST https://apiqr.folowise.com/api/v1/links \
  -H "Authorization: Bearer $QRINDO_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "target_url": "https://example.com/spring-sale",
    "title": "Spring Sale 2026"
  }'

4. Subscribe to scan events

POST /api/v1/webhooks
{
  "url": "https://yourapp.com/hooks/qrindo",
  "events": ["scan.created", "link.updated"]
}

# Verify signature on receive (Stripe-style):
# Qrindo-Signature: t=...,v1=hex(hmac_sha256(secret, t + "." + body))

Three ways to authenticate, one mental model

API keys — recommended

Long-lived, scoped per workspace. Paste into your backend env. Best for the 90% case.

OAuth 2.0 client credentials

Short-lived JWTs, JWKS-rotated signing keys, easy to slot into compliance reviews.

OAuth 2.0 + PKCE — on request

For SaaS partners who want to act on behalf of a Qrindo user. Email us to onboard.

SDKs

The REST API is live today. A first-class TypeScript SDK is in preview (Python and Kotlin to follow). Until it ships on npm, call the API directly:

curl https://apiqr.folowise.com/api/v1/links \
  -H "Authorization: Bearer $QRINDO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target_url":"https://example.com"}'