Authentication
API keys, signed URLs, and when to use each.
Every request carries an API key. It can travel in three places, and the precedence is fixed:
- the
X-Access-Keyheader — recommended; - an
access_keyfield in a JSON body; - an
access_keyquery parameter.
If two of them carry different keys, the request is rejected with request_not_valid. Guessing which one you meant would be worse than failing.
Signed GET URLs
A signed URL lets you put a capture directly in an <img src> without giving whoever views the page the ability to change its parameters.
canonical = the raw query string, with the "signature" parameter removed
signature = hex(HMAC_SHA256(signing_secret, canonical))
Order and encoding are preserved exactly as you send them: sign what you are about to send, and no canonicalisation rules can drift between us.
Add expires (a Unix timestamp in seconds) to make a URL short-lived. Signed GETs cannot carry inline HTML, Markdown, storage credentials or a provider key.
Turn on Require a signature on every GET in the dashboard to reject unsigned GETs entirely, even with a valid key.
Rotation
Rotating the signing secret keeps the previous one valid for 24 hours, so URLs already published keep working while you redeploy.