The Scrape API, like all of ScreenshotMAX’s APIs, is organized around REST. It is designed to use predictable, resource-oriented URL’s and to use HTTP status codes to indicate errors.
Your access key is your unique authentication key to be used to access ScreenshotMAX APIs.
To authenticate your requests, you will need to append your access key to the base URL as a query parameter for GET requests.
You can also use the X-Access-Key header to pass your access key.
You can find your access key in your account dashboard.
The URL of the webpage you want to rendering of. Must be a valid URL and accessible from the internet.
If the URL contains a querystring, it must be URL-encoded.For example, https://example.com/test?param=1 should be passed as https%3A%2F%2Fexample.com%2Ftest%3Fparam%3D1.
The format of the screenshot. Available formats are html, md.
The html format returns the HTML content of the webpage, while the md format returns the content in Markdown format.
The resources to block. Options include document, stylesheet, image, media, font, script, texttrack, xhr, fetch, eventsource, websocket, manifest and other.
The name of the attachment, without the extension filename. This is the name that will be used when downloading the response.
Extension will be automatically added based on the format parameter.
The authorization header to use for the request. This should be a base64-encoded string (e.g., for Basic Auth, encode “username:password” using base64). This allows you to authenticate with the webpage before capturing the content.
The IP location to use for the request. This allows you to simulate requests from different countries by routing them through proxy servers with corresponding IP addresses.
This feature is only available on scale paid plan.Supported locations:
The proxy to use for the request. This allows you to route the request through a different IP address.
The proxy must be in the format http://username:password@host:port or https://username:password@host:port.
The conditions to wait for before rendering. This allows you to ensure that specific elements are loaded before capturing the content.
Available options include:
load: Wait for the load event to be fired.
domcontentloaded: Wait for the DOMContentLoaded event to be fired.
networkidle0: Wait for no network connections for at least 500 ms.
networkidle2: Wait for no more than 2 network connections to be active for at least 500 ms.
Whether to include the metadata icon in the response. This allows you to capture the favicon of the webpage. The link of the icon will be included in the header X-Screenshotmax-Metadata-Icon.
Whether to include the metadata title in the response. This allows you to capture the title of the webpage. The title will be included in the header X-Screenshotmax-Metadata-Title.
Whether to include the metadata fonts in the response. This allows you to capture the fonts used on the webpage. The fonts will be included in the header X-Screenshotmax-Metadata-Fonts.
Whether to include the metadata hash in the response. This allows you to capture the hash of the webpage. The hash will be included in the header X-Screenshotmax-Metadata-Hash.
Whether to include the metadata status in the response. This allows you to capture the HTTP status code of the webpage. The status code will be included in the header X-Screenshotmax-Metadata-Status.
Whether to include the metadata headers in the response. This allows you to capture the headers of the webpage. The headers will be included in the header X-Screenshotmax-Metadata-Headers.
The time-to-live (TTL) for the cache in seconds. This allows you to set a maximum time for the cached resources to be valid. Maximum is 30 days in seconds (2592000).
The callback URL for asynchronous processing. This allows you to receive the response via a webhook.
The webhook will be triggered when the response is ready.
The webhook URL must be a valid URL and must be accessible from the internet.
The webhook URL must be HTTPS and must support the POST method.
More information about webhooks can be found in the async & webhook documentation.
Indicates whether the webhook request should be signed. Enabling this option allows you to verify the authenticity of incoming webhook requests.
For more details, refer to the async & webhook documentation.
The cryptographic signature used to verify the authenticity of the request.
For more information on how to compute and validate this signature, see the signed requests documentation.
Whenever you make a request that fails for some reason, an error is returned also in the JSON format. The errors include an error code and description, which you can find in detail below.
Code
Type
Details
200
OK
The request was successful.
400
Bad request
The request was malformed or invalid.
401
Unauthorized
The request was rejected due to an invalid access key or missing signature when signed requests are enabled.
403
Forbidden
The signature provided is invalid. Occurs when signed requests are enabled.
402
Payment Required
Access denied due to an unpaid invoice. Applies to paid plans.
423
Locked
The request was denied due to insufficient quota.
429
Too Many Requests
The rate limit has been exceeded (too many requests per minute).
500
Internal server error
The request failed due to an internal server error.