Skip to main content
Send your Scrinly API key as a bearer token on every customer API request.
Keys are account-scoped. Jobs, crawls, and schedules can only be read or changed by the account that created them. A resource owned by another account returns 404 so identifiers cannot be probed.

​
Getting a key

Enter your email at the Scrinly dashboard. We send a sign-in link that works once and expires in 15 minutes — there is no password. A new address gets an account on the free plan and its first key straight away.

​
Managing keys

The dashboard lists every live key by prefix, label, and last-used date, and you can hold up to five at a time. A key’s secret is shown exactly once at creation and stored only as a hash, so a lost key is revoked and replaced rather than recovered. Revoking takes effect immediately: the next request using that key returns 401. Keys are scoped to your account — a key id belonging to another account cannot be revoked and returns 404.

​
Key safety

  • Keep keys on your server. Do not embed them in browser JavaScript or mobile applications.
  • Never commit keys to source control or include them in logs.
  • Rotate a key immediately if it is exposed.
  • Use separate keys for local development, CI, and production.

​
Legacy query authentication

GET endpoints accept api_key as a compatibility fallback for browser contexts where a header cannot be supplied.
Query-string credentials can appear in browser history, proxy logs, monitoring tools, and referrer data. Prefer the Authorization header. Never put a provider BYOK credential in a URL.

​
Provider keys

A request that interprets a blueprint may include an ephemeral provider key in a separate header:
Authorization still contains the Scrinly key. Provider keys are accepted only in this header and are not stored, echoed, or logged. See Page blueprints.

​
Authentication responses