#
⚡ SpeedyShot API
If you do not need immediate results, we recommend using the Bulk API for even better performance.
#
Capabilities
The SpeedyShot API can be used for the following main purposes.
- Creating snapshots (.jpeg, .webp)
- Creating PDFs
- Crawling HTML
- Crawling Text
These are only the main purposes, but along with integrations, and the scalability SpeedyShot provides, it can be used for many different goals.
#
Usage
#
Service URL
The SpeedyShot capture service is located at
https://service.speedyshot.com/api/snap
This service only accepts POST
requests, as this is a safer way to work with API keys.
#
Authentication
The service require authentication in order to be used. We accept API keys as a form of authentication, to be set in the header of your request.
Authorization
Your SpeedyShot API Key
#
Response Codes
Our API's response code follows the most common standards. Below is an overview of the codes and their meanings.
- HTTP 200: Successful request
- HTTP 401: API Key was not accepted
- HTTP 403: User account is disabled, or free account is out of credits
- HTTP 500: An error occurred processing your request. See the
response.serviceErrorMessage
field. - HTTP 502: The service is not reachable, and we are probably provisioning an extra service to handle the extra load.
#
Response Object
The response contains data in 3 locations:
- HTTP Status Code
- HTTP Headers
- HTTP Response Body (always
application/json
formatted)
#
Response Headers
Any request to SpeedyShot will contain the following headers:
x-credits-remaining-before
The amount of credits remaining for the account matching the API key, before the request was processed.
x-credits-refill-timestamp
The UNIX timestamp when the credits will be reset for the account matching the API key.
x-api-call-id
A unique API call ID that can be tracked back to our systems. This allows us to help you if any specific issues would occur on a specific API call.
x-ratelimit-limit
x-ratelimit-remaining
#
Response Body
The response body is divided into two types of requests.
- File requests
- Inline requests
#
File Responses
File requests are used for file responses (for example, images and PDFs). These typically include the following data:
{
"fileUrl": string,
"consoleOutput": string[]
}
- The
fileUrl
contains the URL to the file generated. - The
consoleOutput
contains the console output during this request, if theconsoleOutput=true
option was given during the initial request.
Generated files are only accessible for 3 minutes after generation.
If you need to keep these files for a longer period, consider storing them on your system.
#
Inline Responses
Inline responses are currently used for html
and text
output requests.
When using inline requests, make sure to provide the encoding=inline
option. This allows us to be backwards-compatible during our future changes.
💡 We are planning to implement a change to also have these options upload file responses, as this allows us to respond with larger file-sizes.
For a text request, the response would look like the following:
{
"url": string,
"data": {
"text": string,
"title": string
},
"consoleOutput": string[]
}
For an html request, the response would look like the following:
{
"url": string,
"data": {
"html": string,
"title": string
},
"consoleOutput": string[]
}
#
Auto-Scaling
While we offload the critical workload to serverless functions, allowing us to run an incredible amount of requests at the exact same second, we do still use traditional servers as a gateway.
This gateway will automatically scale-up and scale-down to handle the load of all our users and provide the best experience. When this happens, you could potentially encounter an HTTP 502 error, although this should be a very rare occurrence.