ScreenshotNeo

BlogHow-to

How to Use the ShrinkTheWeb API with Python

Learn what the available ShrinkTheWeb documentation confirms, what you must verify before writing a Python integration, and a documented screenshot API alternative.

By the ScreenshotNeo team4 October 20268 min read

Direct answer: The available ShrinkTheWeb integration guide does not provide a Python API recipe. It is a Drupal guide last updated in 2019. It describes historical Access and Secret keys, screenshot options, caching, and features that could require an upgraded account, but it does not establish a current API endpoint, authentication scheme, request parameters, response format, or Python SDK. You should confirm those details in current official documentation before sending requests. Do not copy another screenshot API’s code and label it ShrinkTheWeb code.

The Drupal project’s status is a separate matter: Drupal.org labels its module unsupported and obsolete, with no supported stable releases. That warning applies to the Drupal integration; it does not establish whether ShrinkTheWeb’s underlying API is available. Read the historical Drupal setup guide and check the Drupal project status.

1. What the available documentation does and does not establish

Question What can be said responsibly
Does ShrinkTheWeb generate screenshots or thumbnails? The historical integration material describes a website screenshot and thumbnail service.
How did the Drupal integration authenticate? The 2019 Drupal guide describes retrieving an Access key and Secret key from a profile. It does not establish that these are the current API’s authentication method or explain request signing.
What capture options exist? The guide mentions specific-page captures and custom sizes. It does not establish the current parameter names, accepted values, or complete option set.
How should images be cached? The guide discusses configuring where generated thumbnails are cached. It does not document current cache headers, refresh controls, or service-side caching behavior.
Is there a Python SDK or a current Python example? The available sources do not establish either.
What are current prices, quotas, endpoint, and response format? They are not verified by the available primary documentation.

Some features historically required an upgraded account, but that does not tell you today’s plan requirements. A third-party index published a dated pricing snapshot in 2026, but it is not a substitute for current official terms; do not rely on it to budget an integration. See the dated third-party snapshot.

2. Verify the API before writing the client

Find current documentation from ShrinkTheWeb itself, then confirm each item below. If the official reference or account dashboard does not answer one, ask the service operator before implementing it.

  1. Service availability: confirm that API access is currently offered and that your account can use it.
  2. Endpoint and HTTP method: record the exact URL, method, and whether requests use query parameters, form data, or a JSON body.
  3. Authentication: confirm which credentials are current, where to obtain them, and whether a signature, timestamp, or other value is required. The historical Access and Secret keys alone do not specify how to authenticate a request.
  4. Target URL rules: check URL encoding, accepted schemes, redirects, private or local addresses, and any restrictions on target sites.
  5. Capture parameters: verify the exact names, types, defaults, and account requirements for page selection, image dimensions, and any other options you need.
  6. Response contract: determine whether success returns image bytes, JSON containing a URL, or another format. Check content types, error bodies, redirects, and whether an image is immediately ready.
  7. Limits and billing: confirm request quotas, concurrency, pricing, and how errors or retries affect usage.
  8. Refresh and cache behavior: learn how to request a fresh image, how long a result may be reused, and whether the service provides cache headers or identifiers.

Keep a dated copy or link to the current reference with your integration notes. API behavior and plan terms can change; a historical Drupal module is not a reliable specification for a current Python client.

3. Python request structure—fill in only from current official docs

The following is a deliberately non-runnable template. It shows where a Python HTTP client fits, but uses no invented ShrinkTheWeb endpoint, credential field, parameter, or response contract. Replace every marked value only after confirming it in current official documentation. Do not run it as-is.

import requests

# Replace these values using the current official ShrinkTheWeb API reference.
API_ENDPOINT = "REPLACE_WITH_DOCUMENTED_ENDPOINT"
AUTH_FIELDS = {
    "REPLACE_WITH_DOCUMENTED_AUTH_FIELD": "REPLACE_WITH_SECRET"
}
CAPTURE_FIELDS = {
    "REPLACE_WITH_DOCUMENTED_TARGET_URL_FIELD": "https://example.com"
    # Add only capture options and names documented by ShrinkTheWeb.
}

response = requests.get(
    API_ENDPOINT,
    params={**AUTH_FIELDS, **CAPTURE_FIELDS},
    timeout=(5, 60),  # Choose limits that fit the documented API behavior.
)
response.raise_for_status()

# Do not assume the response is an image. Follow the documented response format.
# If the docs confirm raw image bytes, validate the content type and then save:
# with open("thumbnail.png", "wb") as image_file:
#     image_file.write(response.content)

This template assumes GET only to make the placeholders easy to see; the actual API may require another method or request body. Change the method and request construction to match the current reference. The timeout values are client-side examples, not ShrinkTheWeb service limits.

Handle the documented response deliberately

Once you have the response contract, implement the matching branch. If it returns image bytes, check the HTTP status and expected media type before writing the body. If it returns JSON with an image URL or job identifier, parse that documented field and follow the documented retrieval or polling process. Never save an error page or JSON body with a .png extension and assume it is a screenshot.

# Example pattern for a documented raw-image response only.
content_type = response.headers.get("Content-Type", "").lower()
if not content_type.startswith("image/"):
    raise ValueError(
        f"Expected an image response; received Content-Type: {content_type or 'missing'}"
    )

with open("thumbnail", "wb") as image_file:
    image_file.write(response.content)

Choose the output extension from the documented format or response metadata; the sample intentionally does not claim a ShrinkTheWeb output format.

4. cURL and Node.js equivalents

There is not enough verified information here to give honest, runnable ShrinkTheWeb commands in another language either. Once the official reference supplies the endpoint, authentication, parameters, and response contract, cURL can help isolate whether a problem is in the service request or the Python application. Build the cURL request from that reference; avoid placing real secrets in shell history or shared logs.

For Node.js, follow the same documented contract with the HTTP method and body format the API requires. Do not assume a URL query, bearer token, JSON response, or raw image response without confirmation.

5. Caching, reliability, and cost

Cache with a clear refresh policy

The historical Drupal guide makes caching part of the integration setup, but does not specify a current API cache policy. In your application, decide how long your own generated thumbnail can be reused based on how often the source page changes and your product’s freshness needs. Include the normalized target URL and relevant capture options in your cache key so different sizes or page choices do not collide. Provide an explicit refresh path if users need a new capture. Confirm service terms before storing or redistributing results.

Make failures visible and retries bounded

  • Set connection and overall request timeouts appropriate to your application.
  • Record request identifiers and status information if the service documents them; redact credentials and sensitive target URLs in logs.
  • Retry only transient failures, with a small bounded retry policy and backoff. Do not retry authentication or invalid-parameter errors unchanged.
  • Make repeated jobs safe: avoid creating duplicate work when your application retries after a network interruption.
  • Track whether failure occurred during connection, API response handling, image download, or local storage.

Estimate cost from verified terms

No current ShrinkTheWeb price, quota, or billing rules are verified by the available official material. Before launch, confirm the current plan, included usage, overage behavior, and whether unsuccessful captures are billable. Estimate demand from expected unique captures and refresh frequency, then account for retries and multiple variants. Do not treat a third-party pricing snapshot as a quote.

6. Troubleshooting

Symptom Likely cause What to check
401 or 403 response Credentials, account access, or signing may be wrong or outdated. Use the current official authentication instructions; check account access and ensure secrets are not truncated or URL-encoded incorrectly.
400 response or parameter error A field name, value, request method, or target URL does not match the current API contract. Compare the serialized request with the current docs, including URL encoding and required fields.
Python cannot connect or times out Network or DNS trouble, an unsuitable timeout, or slow capture processing. Separate connection timeout from read timeout, check outbound access, and use the service’s documented asynchronous flow if one exists.
Saved file is not an image The response may be an error document, JSON, a redirect, or a job status. Inspect status, content type, and the documented response body before saving bytes.
Thumbnail shows an unexpected page The service may have followed a redirect, captured a default page, or interpreted a page-selection option differently than expected. Confirm target URL and capture parameter semantics in current docs; test with a public page you control.
Options work in one account but not another A feature may depend on account level; the historical guide noted that some features required an upgrade. Confirm current plan requirements with official account documentation. Do not infer today’s limits from the 2019 guide.
Drupal instructions do not map to Python The guide describes a Drupal module configuration, not a Python client or current API specification. Use it only as historical context and obtain the current API contract separately.

7. Or skip the browser setup

If your goal is simply to capture a website from Python, ScreenshotNeo provides a documented screenshot API. Its API reference is at screenshotneo.com/docs. This call requests a WebP screenshot of Stripe:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Equivalent cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Equivalent Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.

8. Frequently asked questions

Does ShrinkTheWeb have an official Python SDK?

The available research does not establish whether one exists. Check current official API documentation or ask the service operator.

Can I use the old Drupal Access and Secret keys in Python?

The historical guide says the Drupal integration used those keys. It does not establish current API authentication rules, so verify before using them in a new client.

Does the unsupported Drupal module mean the screenshot API is discontinued?

No such conclusion follows from the Drupal project’s status. The status applies to that integration project, not necessarily the separate API service.

What is the safest next step?

Obtain the current official API reference and verify availability, authentication, request fields, response handling, and account terms before implementing a production client.