Abstract Screenshot API Rate Limits and How to Handle 429 Errors

Short answer: Treat HTTP 429 as a signal to slow your client. Check the response for Retry-After and wait for its stated duration if present. If it is absent, retry only a limited number of times with capped exponential backoff and jitter. Reduce concurrency, pace requests to your plan’s per-second limit, cache reusable screenshots, and avoid submitting duplicate work while a request is still pending.

Abstract’s published limits distinguish a total request allowance over a subscription term from a requests-per-second (RPS) threshold. You can hit the per-second threshold even while you still have requests left in your plan. Abstract currently lists its Free plan at 100 requests and 1 request per second, and Standard at 3 requests per second. Standard’s displayed total allowance differs between the annual and monthly billing views, so confirm the billing period and plan in your account before relying on a total quota. Abstract’s product page has the current plan details. Abstract’s terms describe how repeated RPS threshold exceedances may result in an automatic upgrade on eligible plans; for the highest available or custom plans, continued excess may lead to rate limiting or other remedial action under the applicable terms.

What the limits mean

Plan quota and request rate answer different questions:

Limit	What it constrains	How to respond
Total requests	How many requests your subscription allows during its term, which may be monthly or annual.	Check usage and billing period in your account. Reduce unnecessary captures or choose a plan that fits the workload.
Requests per second	How quickly requests may be sent. A burst can exceed this threshold before the total quota is used.	Set a client-side rate limit, reduce concurrent work, and queue requests when demand exceeds the allowed rate.

A 429 says the server considers the request rate too high for a period. It does not, by itself, tell you which account condition caused it. The sources reviewed do not document a Screenshot API-specific 429 body, guarantee a Retry-After header, or establish a particular set of X-RateLimit headers. Inspect the actual response and current endpoint documentation rather than assuming a header name, reset time, or error payload.

Inspect a 429 response before retrying

1. Record the HTTP status, request time, elapsed time, and the response headers and body you actually received.
2. Look for Retry-After. If present and valid, wait at least that long before the next attempt.
3. If absent, use a finite retry policy with exponential backoff and random jitter.
4. Lower concurrency or pace requests to the RPS limit for your current plan.
5. Check account usage and billing period separately from the RPS setting.
6. After the retry limit, surface the failure or put the task back in a queue with an operational alert. Do not keep retrying in a tight loop.

Abstract’s general 429 guidance recommends following Retry-After when the response includes it. Its general rate-limit guidance also recommends stopping immediate retries and using exponential backoff with jitter. These are general recommendations, not a guarantee about what the Screenshot API returns on every 429. See Abstract’s HTTP 429 guide and API rate-limit guide.

Retry policy: bounded backoff with jitter

For a retry number n starting at zero, a common fallback is a capped exponential delay plus random jitter: delay = random(0, min(cap, base × 2^n)). Use a small base delay, a reasonable cap for your workflow, and a finite maximum attempt count. These values are client policy choices, not Abstract-defined reset intervals. If the server supplies a valid Retry-After, use that delay instead of retrying sooner. For an HTTP-date value, parse the date and wait until that time; clamp negative delays to zero.

Only retry a 429 automatically. Other failures may require different handling. For example, authentication or invalid-input errors generally need configuration changes, not repeated requests. A screenshot request may have cost or side effects according to the provider’s own rules, so do not replay non-429 failures blindly. Preserve the URL and capture options for each queued task so a delayed retry reproduces the intended capture.

Python example

This complete example uses the documented Abstract endpoint and a placeholder API key. Confirm the current endpoint parameters and authentication method in Abstract’s documentation for your account. It honors either integer-seconds or HTTP-date Retry-After values when provided, and falls back to bounded exponential backoff with jitter. It writes the successful image response to a file.

import email.utils
import random
import time
from datetime import datetime, timezone

import requests

API_KEY = "YOUR_ABSTRACT_API_KEY"
TARGET_URL = "https://example.com"
ENDPOINT = "https://screenshot.abstractapi.com/v1/"
MAX_ATTEMPTS = 5  # Includes the initial request.
BASE_DELAY_SECONDS = 1.0
MAX_DELAY_SECONDS = 30.0


def retry_after_seconds(value):
    if not value:
        return None
    value = value.strip()
    try:
        return max(0.0, float(value))
    except ValueError:
        pass
    try:
        retry_at = email.utils.parsedate_to_datetime(value)
        if retry_at.tzinfo is None:
            retry_at = retry_at.replace(tzinfo=timezone.utc)
        return max(0.0, (retry_at - datetime.now(timezone.utc)).total_seconds())
    except (TypeError, ValueError, OverflowError):
        return None


session = requests.Session()
for attempt in range(MAX_ATTEMPTS):
    try:
        response = session.get(
            ENDPOINT,
            params={"api_key": API_KEY, "url": TARGET_URL},
            timeout=(10, 90),
        )
    except requests.RequestException as exc:
        # Transport errors are not 429 responses. Surface them for separate handling.
        raise SystemExit(f"Request failed before an HTTP response: {exc}")

    if response.status_code == 429:
        print("429 response headers:", dict(response.headers))
        print("429 response body:", response.text[:1000])
        if attempt + 1 == MAX_ATTEMPTS:
            raise SystemExit("Rate limit persists after the retry limit")
        delay = retry_after_seconds(response.headers.get("Retry-After"))
        if delay is None:
            ceiling = min(MAX_DELAY_SECONDS, BASE_DELAY_SECONDS * (2 ** attempt))
            delay = random.uniform(0.0, ceiling)
        time.sleep(delay)
        continue

    response.raise_for_status()
    content_type = response.headers.get("Content-Type", "")
    if not content_type.startswith("image/"):
        raise SystemExit(f"Expected an image, received Content-Type: {content_type!r}")
    with open("screenshot.png", "wb") as output:
        output.write(response.content)
    print("Saved screenshot.png")
    break
else:
    raise SystemExit("No screenshot was saved")

Abstract’s product page describes its Screenshot API as accepting a URL or raw HTML and returning an image in formats including JPEG, PNG, and GIF. The example uses the API key and URL parameter pattern shown in the endpoint documentation; check that documentation for any current options and exact response behavior.

cURL: inspect the response

Use -i to see the response headers and status while diagnosing an error. This command makes one request and does not automatically retry:

curl -i --get "https://screenshot.abstractapi.com/v1/" \
  --data-urlencode "api_key=YOUR_ABSTRACT_API_KEY" \
  --data-urlencode "url=https://example.com"

Once a request succeeds, save the response body to a file rather than printing binary image data to the terminal:

curl --fail --get "https://screenshot.abstractapi.com/v1/" \
  --data-urlencode "api_key=YOUR_ABSTRACT_API_KEY" \
  --data-urlencode "url=https://example.com" \
  --output screenshot.png

For a production client, put retry logic in a script or application that can parse headers, apply a finite policy, and distinguish an image response from an error response. Avoid placing a real API key in shell history or logs.

Node.js example

This example uses Node.js’s built-in fetch, available in current Node.js releases. It retries 429 responses only, parses the two common Retry-After formats, and writes the image to disk.

import { writeFile } from "node:fs/promises";

const endpoint = "https://screenshot.abstractapi.com/v1/";
const apiKey = process.env.ABSTRACT_API_KEY;
const targetUrl = "https://example.com";
const maxAttempts = 5;
const baseDelayMs = 1_000;
const maxDelayMs = 30_000;

if (!apiKey) throw new Error("Set ABSTRACT_API_KEY in the environment");

function retryAfterMs(value) {
  if (!value) return null;
  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);
  const dateMs = Date.parse(value);
  return Number.isNaN(dateMs) ? null : Math.max(0, dateMs - Date.now());
}

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
  const query = new URLSearchParams({ api_key: apiKey, url: targetUrl });
  const response = await fetch(`${endpoint}?${query}`, {
    signal: AbortSignal.timeout(100_000),
  });

  if (response.status === 429) {
    console.error("429 headers:", Object.fromEntries(response.headers));
    console.error("429 body:", (await response.clone().text()).slice(0, 1_000));
    if (attempt + 1 === maxAttempts) throw new Error("Rate limit persists after retry limit");
    const serverDelay = retryAfterMs(response.headers.get("retry-after"));
    const ceiling = Math.min(maxDelayMs, baseDelayMs * (2 ** attempt));
    const delay = serverDelay ?? Math.random() * ceiling;
    await sleep(delay);
    continue;
  }

  if (!response.ok) {
    throw new Error(`Screenshot request failed: HTTP ${response.status} ${await response.text()}`);
  }
  const contentType = response.headers.get("content-type") ?? "";
  if (!contentType.startsWith("image/")) {
    throw new Error(`Expected image response, received ${contentType || "no Content-Type"}`);
  }
  await writeFile("screenshot.png", Buffer.from(await response.arrayBuffer()));
  console.log("Saved screenshot.png");
  break;
}

Prevent 429s with pacing, queues, and caching

• Set a rate limiter below the documented ceiling. A small margin helps absorb scheduling bursts and uncertainty about concurrent workers.
• Bound concurrency. Multiple workers can collectively exceed an account limit even if each worker appears modest. Coordinate them with a shared queue or distributed limiter.
• Queue excess demand. A queue smooths bursts and lets workers process captures at a controlled rate. Avoid launching a large batch of simultaneous requests unless the API’s current documentation explicitly supports that pattern.
• Deduplicate pending work. If several jobs request the same URL and options, let them share one in-flight capture where appropriate.
• Cache completed screenshots. Reuse a result while its content is fresh enough for your use case. Include relevant capture settings in the cache key, such as viewport, format, and any options that change the output.
• Measure actual responses. Record status, latency, retry count, and received headers. Do not build logic around undocumented rate-limit headers.
• Separate rate errors from quota management. Track total usage against the applicable monthly or annual allowance independently of per-second pacing.

A retry policy improves recovery from temporary throttling, but it does not increase the permitted rate. If sustained demand is above your plan’s published threshold, pace the work or confirm an appropriate plan with the provider. Abstract’s legal terms describe possible consequences of repeated threshold exceedance; review the applicable terms before relying on automatic upgrades or overage behavior.

Batch processing and automatic retries

Abstract’s changelog entry dated April 9, 2024 describes enhanced error handling for batch-processing requests, including detailed error reporting, standardized error codes, and automatic retries for failed tasks. That entry concerns batch-processing tasks. It does not establish that ordinary single screenshot requests that receive HTTP 429 are automatically retried. Implement and observe the retry behavior your own client needs, and verify current batch semantics in the provider documentation before depending on them.

Troubleshooting common 429 problems

Symptom	Likely cause	What to do
429 appears during a burst, but later requests work	Requests per second exceeded even though total plan usage remains.	Lower concurrency, pace requests, and queue bursts. Check the RPS limit for the active plan.
429 continues after a long pause	The cause may be a sustained rate, account or plan condition, or another restriction; the reviewed sources do not define the exact Screenshot API response mapping.	Inspect the actual response, account usage and plan, and current endpoint documentation. Contact Abstract support with timestamps and captured headers if it remains unclear.
Your retry loop makes the problem worse	Immediate retries add more traffic while the service is throttling the client.	Stop the loop. Honor a received Retry-After; otherwise use capped backoff with jitter and a finite attempt limit.
Some workers receive 429 while others do not	Workers may be sharing one account limit without sharing a limiter.	Coordinate rate limiting across all workers and processes, not just within each process.
You cannot find Retry-After	The response may not include it; its presence is not documented as a Screenshot API guarantee.	Use bounded backoff with jitter and capture the headers actually returned. Do not assume a fixed reset interval.
A retry saves an error page as an image	The client may be writing an error body without checking the status or content type.	Check the HTTP status first, then validate Content-Type before saving the body as an image.
Usage looks available but requests still fail	Total quota and per-second threshold are separate constraints.	Review both the subscription-term allowance and RPS threshold for the current plan and billing view.

Performance, reliability, and cost considerations

Performance

Rate limiting trades burst speed for predictable throughput. A queue adds waiting time during peaks, while pacing avoids repeated failed work. Cache hits and deduplication can reduce the number of captures that need to be sent. Keep timeouts long enough for the endpoint’s normal capture latency, but finite so stalled requests do not occupy workers indefinitely.

Reliability

Use a bounded retry count, a delay cap, jitter, and an alert or dead-letter path when retries are exhausted. Make retries observable with structured logs that include the target identifier, attempt count, status, elapsed time, and actual response headers. Avoid logging API keys or sensitive target URLs. Treat connection timeouts and server errors under separately chosen retry rules; the example intentionally retries only 429 so it does not silently replay every kind of failure.

Cost and quota

Retries are additional requests and may count toward the provider’s total allowance depending on its billing rules; confirm this in the current plan documentation. Prevent avoidable retries by pacing before sending, and lower total capture volume through caching and request deduplication. Check the billing period carefully: Abstract’s Standard total quota is displayed differently in its monthly and annual views. Do not infer a monthly allowance from the annual figure, or vice versa.

Or skip the browser setup

If your goal is to get reliable screenshots without operating a browser capture stack, ScreenshotNeo is a website screenshot API and MCP server for developers. It accepts a URL in one GET request and returns PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

Here is the one-call cURL version; replace the target URL and API key. See the ScreenshotNeo API documentation for request options.

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

There are 1,000 screenshots per month on the free plan with no card required. Paid plans start at $5 for 3,000 screenshots; every feature is available on every plan. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; and an MCP server lets AI agents take screenshots. Sign up for ScreenshotNeo free and get 1,000 screenshots a month with no card.

FAQ

Does every 429 mean the monthly quota is exhausted?

No. The published plan information distinguishes the total subscription-term allowance from the requests-per-second threshold. Check both.

Does Abstract always send Retry-After?

The reviewed sources do not guarantee that the Screenshot API sends this header. Use it when it is actually present; otherwise apply bounded backoff with jitter.

Are single screenshot requests automatically retried?

The cited changelog describes automatic retries for failed batch-processing tasks. It does not confirm automatic retries for ordinary single requests that return 429.

Can I fix throttling by increasing the total plan quota?

Not necessarily. A larger total allowance and a higher requests-per-second threshold are different plan properties. Confirm the RPS limit as well as total quota when selecting a plan.