ScreenshotNeo

BlogHow-to

How to Use ScreenshotAPI.net to Capture WordPress Website Screenshots

Capture WordPress pages with ScreenshotAPI.net from cURL, Python, Node.js, or server-side PHP. Choose image options, handle caching, and troubleshoot common errors.

By the ScreenshotNeo team4 October 20269 min read

Direct answer: ScreenshotAPI.net can capture a WordPress page by sending its URL and your API token to https://shot.screenshotapi.net/v3/screenshot. You do not need a WordPress plugin to make the API request: call it from a server-side script or another backend, then save or use the returned image or PDF. The available research does not confirm an official WordPress plugin, so the PHP example below is an implementation pattern, not an official WordPress integration.

Keep the API key on the server. Do not put it in public page HTML or browser JavaScript, where visitors could copy it. See the ScreenshotAPI.net documentation for the current endpoint and parameter reference.

1. Get your API key and choose a WordPress URL

  1. Sign in to ScreenshotAPI.net and copy your API key from the dashboard.
  2. Choose the page to capture, such as https://example.com/ or a published post URL.
  3. Decide whether you need the visible viewport or the whole page, which output format you need, and whether the page needs time to render dynamic content.
  4. Make the request from a trusted server environment. Avoid putting private tokens in a theme template that is exposed to visitors.

The target URL must be reachable by the screenshot service. A page that requires a logged-in WordPress session may need the documented cookie or authentication options; do not assume that a private admin page will be accessible from a plain URL request.

2. Make a basic request

The endpoint accepts GET and POST requests. For a quick check, use GET with a URL-encoded target address. The response is the requested output, so save the response body as a file rather than expecting JSON metadata.

cURL

curl -G "https://shot.screenshotapi.net/v3/screenshot" \
  --data-urlencode "token=YOUR_API_KEY" \
  --data-urlencode "url=https://example.com/" \
  --data-urlencode "output=image" \
  --data-urlencode "file_type=png" \
  -o wordpress-home.png

Replace YOUR_API_KEY and the target URL. Keep the token private, including in shell history on shared systems.

Python

import requests

endpoint = "https://shot.screenshotapi.net/v3/screenshot"
params = {
    "token": "YOUR_API_KEY",
    "url": "https://example.com/",
    "output": "image",
    "file_type": "png",
}

response = requests.get(endpoint, params=params, timeout=120)
response.raise_for_status()

with open("wordpress-home.png", "wb") as screenshot:
    screenshot.write(response.content)

Install the dependency with python -m pip install requests. The timeout here is a client-side limit; use a value appropriate for your own request flow.

Node.js

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

const params = new URLSearchParams({
  token: process.env.SCREENSHOTAPI_TOKEN,
  url: "https://example.com/",
  output: "image",
  file_type: "png",
});

const response = await fetch(
  `https://shot.screenshotapi.net/v3/screenshot?${params}`,
  { signal: AbortSignal.timeout(120_000) }
);

if (!response.ok) {
  throw new Error(`Screenshot request failed: HTTP ${response.status} ${await response.text()}`);
}

await writeFile("wordpress-home.png", Buffer.from(await response.arrayBuffer()));

Set SCREENSHOTAPI_TOKEN in the server environment before starting the Node process. This example uses Node’s built-in fetch and file APIs.

3. Call the API from WordPress PHP

For a WordPress-triggered capture, make the HTTP request on the server with WordPress’s HTTP API. Add the API key to wp-config.php or a server environment variable, and make the function callable only by an authorized workflow. The example saves the returned image into the WordPress uploads directory and returns its URL. It is a starting point for custom integration, not a plugin supplied by ScreenshotAPI.net.

// In wp-config.php, define the key outside publicly served files:
define( 'SCREENSHOTAPI_TOKEN', 'YOUR_API_KEY' );

// In a small site-specific plugin or trusted server-side code:
function mysite_capture_wordpress_page( $page_url ) {
    if ( ! defined( 'SCREENSHOTAPI_TOKEN' ) || ! SCREENSHOTAPI_TOKEN ) {
        return new WP_Error( 'missing_api_token', 'ScreenshotAPI token is not configured.' );
    }

    $response = wp_remote_get(
        'https://shot.screenshotapi.net/v3/screenshot',
        array(
            'timeout' => 120,
            'query'   => array(
                'token'     => SCREENSHOTAPI_TOKEN,
                'url'       => esc_url_raw( $page_url ),
                'output'    => 'image',
                'file_type' => 'png',
            ),
        )
    );

    if ( is_wp_error( $response ) ) {
        return $response;
    }

    $status = wp_remote_retrieve_response_code( $response );
    $body   = wp_remote_retrieve_body( $response );
    if ( $status < 200 || $status >= 300 || '' === $body ) {
        return new WP_Error(
            'screenshot_api_error',
            'Screenshot request failed with HTTP ' . intval( $status )
        );
    }

    $saved = wp_upload_bits( 'wordpress-page.png', null, $body );
    if ( ! empty( $saved['error'] ) ) {
        return new WP_Error( 'screenshot_save_error', $saved['error'] );
    }

    return $saved['url'];
}

Call mysite_capture_wordpress_page( 'https://example.com/' ) from an authorized server-side process and handle either the returned URL or WP_Error. Do not expose this function through an unauthenticated public endpoint: otherwise it could be abused to consume your API quota. Validate which URLs your workflow allows, especially if a visitor can influence $page_url.

4. Choose capture options for the page

Start with the smallest request that meets the need, then add options from the official parameter reference. The endpoint documents image and PDF output, file formats, viewport dimensions, full-page capture, timing controls, CSS and JavaScript injection, cookies and authentication, and other browser settings. Parameter availability and exact accepted values should be checked in the current docs.

Need Option to consider Practical note
Capture content below the fold full_page=true Use for long articles and landing pages. Very long or continuously loading pages can take longer or produce unexpectedly large files.
Control image output output=image and file_type PNG is useful when crisp text or lossless output matters; JPEG and WebP may suit smaller image delivery. Confirm format support in the docs.
Capture a document PDF output Use the documented PDF controls for page layout and output needs; image-only settings may not apply.
Set the browser viewport width and height Match the intended desktop or mobile layout. A viewport capture and a full-page capture answer different questions.
Wait for a JavaScript-rendered page Documented wait or timing options Wait only as long as the page needs. A fixed delay can be wasteful; use a page readiness condition when the API supports one.
Alter what is rendered CSS or JavaScript injection; hide elements Useful for removing a page element or setting a capture state. Keep injected code scoped to the capture and avoid changing production content.
Capture a protected view Documented cookies or authentication options Treat cookies and credentials as secrets. Use a restricted account and avoid logging request URLs that contain sensitive values.
Refresh a previously cached result fresh=true Request a new render rather than reusing a cached result. See the cached and fresh screenshot documentation.

For example, a full-page PNG request can add full_page=true, width=1440, and height=900 to the basic request. Use the exact option combinations documented for the endpoint; do not assume every setting behaves identically across image and PDF output.

5. Handle caching, freshness, and WordPress storage

ScreenshotAPI.net documents caching controls. With caching enabled, a matching request may return a stored result; fresh=true bypasses the cache and asks for a current capture. Use cached output for stable page previews and force a fresh render when content changes frequently or the capture is part of a check where current state matters. Fresh renders can take longer than cache hits.

In WordPress, the API call and the storage decision are separate. The PHP sample writes the image to uploads, but another workflow could attach it to a media record, store a URL in post metadata, or pass it to a review pipeline. Decide whether repeated captures should overwrite an existing file, use timestamped filenames, or retain versions. Also define cleanup for old files so uploads do not grow indefinitely.

6. Troubleshoot common failures

ScreenshotAPI.net lists authentication, subscription, payment, quota, connection, and timeout errors. See the official errors reference for current codes and descriptions.

Symptom Likely cause What to do
Missing-token or authentication error The token is absent, misspelled, revoked, or not the API key for the account. Check the dashboard key and ensure the request sends it as token. Keep the secret in server configuration.
Inactive subscription or trial-expired error The account plan or trial is not active. Check the account status and billing page before retrying.
Payment-required or quota error Payment is due or the plan’s allowed request usage has been reached. Review usage and account status; adjust capture volume or plan as appropriate. Do not blindly retry a request that cannot succeed.
Rate-limit response Requests per minute exceed the account’s allowance. Reduce concurrency, queue work, and retry with exponential backoff and jitter.
Connection refused or closed The target may be unreachable, refusing automated access, or affected by network or firewall conditions. Confirm the URL is public and correctly formed, then retry later. A screenshot service cannot guarantee that every site’s network policy permits a capture.
Tunnel or proxy connection failure The service could not establish a connection to the target. Check the target address and any proxy-related settings; verify the site is reachable from outside your WordPress server.
Timeout The site is slow, keeps loading, or the client timeout is too short. Check the page directly, use suitable documented wait settings, increase the caller’s timeout, and avoid overly broad captures.
Image is blank or misses content The page requires client-side rendering, delayed assets, authentication, or a particular viewport. Check the page’s public accessibility, choose an appropriate wait setting or viewport, and use supported cookies/auth options only when needed.
PHP saves an unreadable file The response may be an API error body rather than image bytes, or the output/format does not match the filename. Check the HTTP status and response headers/body before saving; use the requested output and matching extension.

For retryable network failures and rate limits, use a bounded retry policy with backoff. Do not retry authentication, inactive-account, or exhausted-quota errors on a tight loop. Log status codes and a request identifier if provided, but redact tokens, cookies, and authorization values.

7. Performance, reliability, and cost considerations

  • Reduce unnecessary work: request only the needed viewport or page length, choose an appropriate format, and avoid forcing fresh renders when a cached preview is acceptable.
  • Control concurrency: queue bulk WordPress jobs instead of starting many remote browser renders at once. Respect account rate limits and use backoff for transient failures.
  • Set realistic timeouts: browser rendering takes longer than a simple image download. Ensure PHP, web server, and job-runner limits allow the request to finish, or move long captures to a background job.
  • Plan for partial failure: store status and retryable failure details alongside each job. A WordPress request timing out does not prove the remote capture failed, so avoid creating duplicate work without checking your workflow state.
  • Track file growth: full-page images and retained historical captures consume more storage than viewport thumbnails. Set retention and cleanup rules.
  • Budget from current account terms: usage limits and prices can change. Check ScreenshotAPI.net’s live pricing and dashboard before committing to a capture volume; the research available for this article does not establish current plan prices.

8. Or skip the browser setup

If you want the capture API without wiring up browser-rendering infrastructure in your own WordPress code, ScreenshotNeo is a website screenshot API and MCP server for developers. Its API takes a URL and returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/ -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo returned HTTP ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) => writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

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; and 1,000 screenshots a month are free with no card, with paid plans starting at $5 for 3,000. Sign up for ScreenshotNeo and start with 1,000 free screenshots a month, no card required.

9. FAQ

Do I need a ScreenshotAPI.net WordPress plugin?

The available sources do not confirm an official plugin. You can call the API from server-side PHP or another backend without installing one.

Can I capture a draft or private WordPress page?

A plain URL request works only when the target can be reached by the screenshot service. Protected pages may require supported authentication or cookies; use the documented options and keep credentials secret.

Why did the screenshot not reflect my latest edit?

A cached result may have been reused. Request a fresh capture with fresh=true when you need the current page state.

Should I run captures during a normal page load?

For slow or full-page captures, a background job is usually easier to manage than holding a visitor’s page request open. Return a status or later result from your own workflow.