API SECURITY

Keep screenshot API credentials behind a trusted server boundary

Authenticate requests with the documented API key header from a backend, worker, CLI, or protected CI job. Never ship the key in browser JavaScript, mobile bundles, public repositories, or shared logs.

One header

Clear authentication

Server only

No browser exposure

Rotate

Contain incidents

Install:x-snapshotsiteapi-key: $SNAPSHOT_SITE_API_KEY

Auth:SNAPSHOT_SITE_API_KEY

Get started for free

Authenticated API request

Snapshot Site themed screenshot API authentication illustration

Good fits

Backend services calling capture endpoints

CI workflows generating visual evidence

Teams separating development and production secrets

Products accepting capture requests from signed-in users

Authentication is only one layer of the boundary

A valid provider key identifies the Snapshot Site account; your application must still authorize its own users, validate destinations, and control output access.

Secret storage

Use a secret manager or protected server environment and restrict who and what can read the key.

Caller authorization

Authenticate the user or service before allowing it to spend quota or create artifacts.

Destination policy

Resolve internal identifiers or validate protocols and allowed hosts before capture.

Result protection

Apply storage, retention, and sharing rules based on the source content's sensitivity.

Implementation workflow

Secure an authenticated request

Provision the key into a trusted runtime through secret management

Accept only authorized application capture requests

Send the key in x-snapshotsiteapi-key over HTTPS

Redact credentials and sensitive URLs from logs

Screenshot API authentication example

Node.js

Read a key from server environment

Fail during startup if the deployment secret is absent, then use it only in the outbound provider request.

const apiKey = process.env.SNAPSHOT_SITE_API_KEY;
if (!apiKey) throw new Error("Missing Snapshot Site API key");

const response = await fetch(
  "https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-snapshotsiteapi-key": apiKey,
    },
    body: JSON.stringify({
      url: "https://example.com",
      format: "webp",
      width: 1440,
      height: 900,
    }),
  },
);

Provider authentication and product authorization are different

The Snapshot Site key authorizes use of the provider account. It does not know which person may capture a page in your product. Your backend must make that decision before creating the outbound request.

Prefer accepting a report, campaign, or page identifier over a completely arbitrary URL. The server can resolve that identifier to a known destination and record the business context. When raw URLs are required, apply protocol, hostname, and product-specific policy.

Reduce the places a key can appear

Load secrets only into runtimes that need them. Do not expose them through client environment prefixes, error pages, analytics payloads, or debugging output. Ensure HTTP libraries redact the header and that test fixtures use placeholders rather than real credentials.

CI systems should inject the key into protected jobs. Pull requests from untrusted forks should not receive production secrets.

Plan rotation before an incident

Document who can create, replace, and revoke credentials. A safe rotation deploys the new value, confirms successful traffic, and then removes the old value. After suspected exposure, rotate first and investigate in parallel.

Generated artifacts also need protection. Store them under application access rules and avoid treating a returned URL as permanently public merely because the request succeeded.

The best practices guide connects authentication to queues, storage, and observability.

Screenshot API Authentication FAQ

How does Snapshot Site authenticate API calls?

Send the account API key through the x-snapshotsiteapi-key header on HTTPS requests to the documented endpoint.

Can I put the key in React or other frontend code?

No. Browser code and public bundles are observable. Send an authorized request to your own backend, which then calls Snapshot Site.

Where should the key be stored?

Use a managed secret store or protected server environment configuration with least-privilege access and audited deployment controls.

How should I rotate a key?

Deploy the replacement through secret management, verify traffic with it, then revoke the previous credential. Avoid a change that leaves no working key during rollout.

Should development and production share a key?

Separate environments when your account setup allows it. Isolation reduces accidental production use and makes incident scope easier to understand.

What should logs redact?

Remove the authentication header, signed URL tokens, sensitive query parameters, and private artifact locations from general application logs.

Does provider authentication authorize my users?

No. Your product must authenticate and authorize its caller, enforce destination rules, and account for quota before making the provider request.

What should I do if a key is exposed?

Remove it from the exposure, rotate or revoke it promptly, inspect usage and logs, and correct the path that leaked it. Deleting a commit alone does not invalidate a secret.

Related resources

Snapshot Site Home Website Screenshot API API Documentation TypeScript SDK Screenshot API Examples Pricing cURL Guide Best Practices Error Handling

Protect the capture boundary

Move the key into server-side secret management, authorize callers, and validate destinations before enabling production traffic.

Get started for free Read the API docs