Once you have more than a handful of dynamic codes, clicking through a console stops scaling. You want your own system to create codes, repoint them, and react when they are scanned — without a person in the loop. That is what an API and webhooks are for: the API lets your code drive redireo, and webhooks let redireo drive your code back. This post covers how both work on redireo today, and is honest about what is not published yet.
How do machine-to-machine API keys work?
A machine-to-machine API key is a secret credential your backend sends on each request to prove it is allowed to act on your account, with no human login involved. On redireo, you create a key in the console and it is shown once — the full secret, prefixed qrd_, is displayed at creation and never again, so you store it in your own secret manager at that moment. Every request then carries it as a bearer token: Authorization: Bearer qrd_…. Keys are revocable, so if one leaks or a service is retired you revoke it and it stops working immediately, without disturbing your other keys. Requests are subject to your plan’s limits, so automated traffic is metered the same way as everything else.
Because the key acts on your tenant, treat it like a password: keep it out of source control, out of frontend bundles, and out of logs. A leaked key can create and repoint your codes, so the “shown once, stored by you, revocable” model exists to keep the secret in as few places as possible.
How do outbound webhooks work?
An outbound webhook is a request redireo sends to a URL you own when an event happens, so your system learns about it in near real time instead of polling. You register a target URL, and when a subscribed event fires, redireo posts the event payload to that URL. Two properties make this safe to rely on:
- HMAC signatures. Each webhook carries a signature computed with a shared secret over the request body. Your endpoint recomputes the HMAC and compares it, which proves the request genuinely came from redireo and was not altered in transit. Reject anything whose signature does not match.
- SSRF-guarded targets. When you register a target URL, redireo guards against server-side request forgery — targets that resolve to internal or private network addresses are refused, so the webhook system cannot be pointed at infrastructure it should never reach.
Together these mean you can trust the source of an event and redireo will only deliver to legitimate external endpoints.
Can you create codes in bulk?
Yes — redireo supports bulk serialized create, up to 500 codes per request, for generating large batches in one call. This is built for variable-data printing and serialized runs: a single request produces a batch of distinct dynamic codes you can then print across a product line, a mailing, or a set of assets. Driving that from the API means your system can generate, track, and later repoint thousands of codes without anyone touching the console. It pairs naturally with the serialized-code needs behind trends like GS1 Digital Link and the EU Digital Product Passport, covered in the linked post — though bulk create is a general primitive, not a compliance product.
Is there a public API portal or OpenAPI spec?
Not yet — API keys, webhooks, and bulk create are shipped and working, but a published public API portal is not something to plan around today. The mechanics described here are live: keyed auth with qrd_ bearer tokens, HMAC-signed and SSRF-guarded webhooks, and 500-per-request bulk create. What is not yet published is a public developer portal with a full OpenAPI specification and self-serve documentation. If your decision depends on a polished public spec being available now, that is the honest gap. If it depends on the underlying capabilities existing and being usable, they do.
See the shipped API surface — keyed auth, signed webhooks, and bulk create — and start automating your codes on the API feature page.