Skip to content

Signed Links

When you share links to the screenshots with your access key in public, there is a problem that everybody can take your API access key and reuse it to take screenshots on their own and exhaust your screenshot quota.

To prevent others from using your API key, you need to:

  1. Sign every request you are going to share publicly.
  2. Require signing for every request.

Then even if the potential unscrupulous person sees or steals your access key, they can’t reuse it until they also steal your secret key (signing key).

You generally don’t need to sign requests if you will not share screenshot links publicly and will use screenshot API only on the server-side.

Signing requests

Singed links do not work with HTTP “POST” requests. The feature is intended to be used for sharing links in public.

To sign the request, like, you need to follow the simple algorithm:

  1. Use your secret to hash the query string access_key=0Ij4LFMtFnGUrA&url= with the HMAC SHA256 algorithm.

  2. Append the signature parameter with the hash:

To hash the query string with your secret key and HMAC SHA256 algorithm in the CLI, you can run the following command:

Terminal window
$ echo -n "access_key=0Ij4LFMtFnGUrA&url=" | openssl sha256 -hmac "m9ajW9br9hTw2A" 130

You can need to apply the same algorithm in the language of your choice.

Require signing

After you start signing requests and make sure that the API accepts your requests, you can require signing every request. Go to the access configuration page and enforce signing every request. The change will be applied immediately, but cached screenshots might not be impacted. That’s it. After this step, unsigned requests with your API access key are not accepted.

Animated screenshots

Animated screenshots also support signed links. There is no difference in the underlying mechanism besides that the URL prefix should be /animate.