Skip to main content

​
API key auth

Every request to /v1/screenshots and /v1/usage requires an API key in the X-API-Key header:
Requests without a valid key, or with a revoked one, get a 401:

​
Creating and managing keys

Keys are created and revoked from the dashboard (API Keys), not the programmatic API — key management itself is authenticated with your session cookie, not another API key. This keeps a compromised key from being used to mint further keys.
  • Shown once. The plaintext key is returned only in the create response. scrnshot stores a SHA-256 hash, not the key itself, so there’s no way to retrieve it again later — if you lose it, revoke it and create a new one.
  • Prefix only, afterward. GET /v1/keys returns each key’s prefix (e.g. sk_live_9f2b) and metadata (name, created/last-used timestamps), never the full value.
  • Revocation is immediate. DELETE /v1/keys/{id} invalidates the key for authentication right away; in-flight requests using it will start failing with 401.

​
Key handling

  • Treat an API key like a password — anyone with it can consume your quota.
  • Don’t embed keys in client-side code (browser JS, mobile apps). Call scrnshot from your backend and proxy results to the client if needed.
  • Use a separate key per environment (e.g. one for staging, one for production) so you can revoke one without affecting the other.

​
Dashboard sessions

The dashboard itself (screenshot gallery, key management, billing) uses an HttpOnly session cookie set on login, not the X-API-Key header. If you’re only integrating the capture API, you can ignore this — it’s not something your code needs to handle.