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:

  1. the X-Access-Key header — recommended;
  2. an access_key field in a JSON body;
  3. an access_key query 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.