API keys

Keys belong to your workspace, not to an individual schedule. The API Keys page has one tab per API —Instant Snap API and Auto Schedule API — so create the key on the tab of the API you are going to call.

The View API Key menu item on an existing key opens a read-only details panel — the name, the prefix, its status and expiry, when it was created and last used, and how many requests it has made. It does not reveal the secret.

wsw_api_0123456789ab_Zm9vYmFyYmF6cXV1eGNvcmdlZ3JhdWx0        # Instant Snap API
wsw_autoapi_0123456789ab_Zm9vYmFyYmF6cXV1eGNvcmdlZ3JhdWx0    # Auto Schedule API

• wsw_api_ or wsw_autoapi_ — a fixed prefix naming the API the key opens, so a leaked key is recognisable in a log or a repository scan and a key sent to the wrong API is refused before anything is looked up.
• 0123456789ab — twelve hex characters identifying the key. This part is not secret and is what the application shows you in the key list.
• The remainder is the secret. It is random, URL-safe, and never stored in readable form.

Send the whole string, all three parts, exactly as it was given to you. Splitting it or sending only the identifier will not authenticate.

Put the key in an X-Api-Key request header. There is no bearer token, no OAuth flow and no query-string alternative — a key in a URL ends up in access logs, browser history and referrer headers, so neither API accepts one.

curl -X POST https://api.websitescreenshotworld.com/instant-snap/v1/captures \
  -H "X-Api-Key: $WSW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

A key opens exactly one API. An Instant Snap API key can capture any url you post; an Auto Schedule API key can fire the schedules you already built. Keeping the two apart means a key that leaks from one integration cannot be turned against the other, and each key list shows only the keys of its own API.

Both APIs draw on the same per-minute allowance of your plan, and a key that has been deleted stops working the instant it is removed. A key presented to the other API is refused with api_key_invalid and a message that names the key it needs.

A missing key, a malformed key, a key that was deleted and a key that never existed all produce the same answer with the same status code. The one exception is a well-formed key of the other API, whose message says so - that reveals nothing, because the prefix already does.

{
  "success": false,
  "error_code": "api_key_invalid",
  "error_message": "\"X-Api-Key\" is invalid"
}

The responses are deliberately identical. Distinguishing “no such key” from “that key was revoked” would let anyone confirm which keys exist by trying them, so the API declines to say.

A key can be given an expiry date when it is created, but most are not, so rotation is a deliberate act. The order matters:

1. Create the new key and copy the secret.
2. Deploy it to every service that calls the API.
3. Watch the key list until the old key’s “last used” stops moving.
4. Delete the old key.

Deleting first inverts that into an outage: the old key stops working the instant it is removed, and in-flight requests carrying it fail with api_key_invalid.

• Keep the key server-side. Anything you ship to a browser or a mobile app is readable, and a key in front-end code can be spent by anyone who opens the network tab.
• Read it from an environment variable or a secret manager rather than committing it.
• Do not log request headers verbatim in an error handler — that is the usual way a key reaches a log aggregator.
• If a key is exposed, create a replacement and delete the exposed one. Both take seconds.