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"}'