Documentation

Introduction

SnapAPI turns any URL into an image. Send an HTTP request with a URL and capture options, and get back a PNG, JPEG, WebP, or PDF file — or a link to one. A second endpoint extracts page content as clean Markdown and structured article data for RAG, indexing, and AI agents. It works with any language, framework, or platform that can make HTTP requests, and with AI assistants through the Model Context Protocol (MCP).

Every screenshot consumes credits based on your plan. You can track usage and balances in the dashboard.

Quickstart

• 1. Get an API key. Sign in and create a key on the API Keys page in the dashboard.
• 2. Send a request. POST the target URL to /api/v1/screenshot.
• 3. Use the result. Receive JSON with a temporary image link, or raw image bytes.

curl -X POST https://snapapi.top/api/v1/screenshot \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

Authentication

All requests must include your API key in the Authorization header:

Authorization: Bearer snap_your_api_key

Create and revoke keys at any time from the API Keys page in the dashboard. Requests without a valid key return 401 Unauthorized.

Screenshot API

POST /api/v1/screenshot — send options as JSON with Content-Type: application/json.

{
  "url": "https://example.com",
  "fullPage": true,
  "format": "png",
  "width": 1280,
  "wait": "networkidle"
}

Parameters

Waiting strategies

Use wait to decide when the page is considered ready:

• domcontentloaded — the HTML has parsed. Fastest; good for simple pages.
• load — images and stylesheets have finished loading.
• networkidle — no network activity for 500ms. Best for JavaScript-heavy pages. Combine with delay for animations or late content.

Output formats

• png — palette-quantized PNG, visually near-lossless: the server recompresses PNG output with pngquant (quality 65–85), typically shrinking large full-page captures by 60–75%. Pick JPEG or WebP for photo-heavy pages where smallest transfer size matters.
• jpeg — smaller files; tune with quality.
• webp — modern format, smaller than PNG or JPEG at the same quality; tune with quality.
• pdf — paginated documents based on the full page.

Responses

JSON (default)

With response: "json" you receive metadata and a temporary link to the captured image. The link is valid for 15 minutes — download or copy the image if you need it longer.

{
  "ok": true,
  "storage": "minio",
  "url": "https://snapapi.top/api/v1/files/...",
  "contentType": "image/png",
  "bytes": 184320,
  "durationMs": 1200,
  "creditsUsed": 1
}

Responses only carry standard HTTP headers. Your credit balance, usage history, and rate-limit status are available in the dashboard — or via the account_info MCP tool for agents.

Binary

With response: "binary" the image bytes are returned directly, with the matching Content-Type. Stream the response straight to a file, an <img> proxy, or object storage:

curl -X POST https://snapapi.top/api/v1/screenshot \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com", "response": "binary"}' \
  --output screenshot.png

Content Extraction API

POST /api/v1/extract renders a page in a real browser and returns its content as Markdown and structured data: clean article text (title, author, publish date, excerpt, body), SEO/Open Graph metadata, a heading outline, and outbound links. Add "html" to formats to also get the raw rendered HTML. Each call consumes credits, and the feature is available on the Starter and Pro plans.

{
  "url": "https://example.com/blog/post",
  "formats": ["markdown", "structured"],
  "wait": "load",
  "maxChars": 100000
}

A successful response looks like this:

{
  "ok": true,
  "url": "https://example.com/blog/post",
  "finalUrl": "https://example.com/blog/post",
  "statusCode": 200,
  "content": {
    "markdown": "# Article title\n\nFirst paragraph ..."
  },
  "structured": {
    "metadata": {
      "title": "Article title",
      "description": "SEO description",
      "ogImage": "https://example.com/cover.png"
    },
    "article": {
      "title": "Article title",
      "byline": "Jane Doe",
      "publishedTime": "2026-08-01T09:00:00.000Z",
      "excerpt": "First paragraph of the article ...",
      "siteName": "Example Blog",
      "length": 8421,
      "text": "Plain-text article body ..."
    },
    "outline": [{ "level": 1, "text": "Article title", "id": "" }],
    "links": [{ "text": "Reference", "href": "https://ref.example" }]
  },
  "truncated": false,
  "bytes": 18432,
  "durationMs": 1100,
  "creditsUsed": 1
}

Response fields:

Structured content

The structured object is included whenever formats contains structured (the default). Its fields are:

For JavaScript-heavy single-page apps, use "wait": "networkidle" plus delay so late content finishes rendering. Text fields longer than maxChars are truncated and truncated is set to true. Non-article pages (login screens, dashboards) return article: null while metadata, outline, and links remain populated.

curl -X POST https://snapapi.top/api/v1/extract \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/blog/post"}'

Scroll Video API

POST /api/v1/video records a real browser smoothly scrolling the page from top to bottom and returns a playable video (MP4/WebM). Sticky headers, scroll animations, parallax, and lazy-loaded images are captured as they appear — the page is pre-scrolled once before recording so lazy content is loaded. Scroll video is available exclusively on the Pro plan. Each call consumes 5 credits. The signed URL expires after 15 minutes, and the platform permanently deletes the file about 60 minutes after upload (the cleanup sweep runs every 30 minutes); use "response": "binary" to stream the bytes directly.

{
  "url": "https://example.com/landing",
  "format": "mp4",
  "fps": 30,
  "speed": 800
}

A successful response looks like this:

{
  "ok": true,
  "storage": "minio",
  "url": "https://snapapi.top/api/v1/files/eyJ...签名令牌",
  "contentType": "video/mp4",
  "bytes": 8421376,
  "durationMs": 21400,
  "frames": 642,
  "width": 1280,
  "height": 800,
  "creditsUsed": 5
}

# JSON mode — get a signed URL (15-minute expiry)
curl -X POST https://snapapi.top/api/v1/video \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/landing"}'

# Binary mode — stream the MP4 directly to a file
curl -X POST https://snapapi.top/api/v1/video \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/landing", "response": "binary"}' \
  --output scroll.mp4

Recording happens in real time, so calls take roughly the scroll duration plus page load (typically 10–35 seconds). Very long pages scroll faster automatically — scroll time is always capped at 30 seconds.

Scheduled Screenshots API

Scheduled screenshots capture a URL on a recurring cron schedule (UTC) and push the result to your webhook URL as a signed JSON payload — no polling required. The feature is available on the Starter plan (up to 20 tasks) and the Pro plan (up to 50 tasks). Each successful run consumes the same credits as a regular screenshot; failed captures are not charged.

Endpoints

Create a task

POST /api/v1/schedules accepts a JSON body with the following fields:

{
  "name": "Daily homepage check",
  "url": "https://example.com",
  "cron": "0 9 * * *",
  "webhookUrl": "https://your.app/hooks/snapapi",
  "options": { "fullPage": true, "format": "jpeg", "width": 1280 }
}

The cron field uses standard five-field syntax — minute, hour, day of month, month, day of week — always evaluated in UTC:

• "0 9 * * *" — every day at 09:00 UTC
• "0 9 * * 1-5" — Monday to Friday at 09:00 UTC
• "*/30 * * * *" — every 30 minutes

The create response (201) returns the full task object, including a per-task webhookSecret (prefixed with whsec_). The secret is also returned by the task-detail and update endpoints; list responses omit it.

curl -X POST https://snapapi.top/api/v1/schedules \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "cron": "0 9 * * *",
    "webhookUrl": "https://your.app/hooks/snapapi"
  }'

Task object & responses

Create (201), detail, and update responses wrap one task as { ok: true, schedule: { … } }; the list endpoint wraps an array as { ok: true, schedules: [ … ] } (newest first, with webhookSecret omitted). The task object:

The remaining endpoints respond with:

• POST …/{id}/trigger — 202 with { ok: true, runId }; the run executes in the background.
• DELETE …/{id} — { ok: true } with 200.
• GET …/{id}/runs — { ok: true, runs: [ … ] } with the 50 most recent runs (newest first). Each run object:

Webhook delivery

After every delivered run, SnapAPI POSTs a JSON payload to your webhookUrl. Runs aborted before capture — for example when the account is out of credits, which pauses the task — are not delivered. Deliveries that return a non-2xx status, time out after 10 seconds, or fail to connect are retried after 1, 5, and 30 minutes; the run is marked failed after the fourth attempt. Redirects are not followed.

Each delivery carries these headers:

• X-SnapAPI-Event — screenshot.completed or screenshot.failed
• X-SnapAPI-Delivery — the run ID
• X-SnapAPI-Timestamp — ISO 8601 delivery timestamp
• X-SnapAPI-Signature — sha256=<HMAC>: the HMAC-SHA256 of the raw request body, keyed with the task's webhookSecret

A completed delivery looks like this:

{
  "event": "screenshot.completed",
  "taskId": "b1e2c3d4-…",
  "runId": "r9f8e7d6-…",
  "url": "https://example.com",
  "screenshotUrl": "https://snapapi.top/api/v1/files/…",
  "contentType": "image/jpeg",
  "bytes": 184320,
  "durationMs": 1200,
  "error": null,
  "timestamp": "2026-08-31T09:00:01.234Z"
}

For screenshot.failed events, screenshotUrl is null and error describes the cause (for example, an unreachable target page). The screenshotUrl link stays valid for 7 days and needs no API key — download or copy the image within that window.

Delivery payload fields:

Verify the signature before trusting a delivery (Node.js example):

const crypto = require("crypto");

function verifySignature(rawBody, signatureHeader, secret) {
  const expected =
    "sha256=" +
    crypto.createHmac("sha256", secret).update(rawBody).digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

Pausing, resuming, and failures

• Pause a task at any time with PATCH /api/v1/schedules/{id} and body { "status": "paused" }; resume with { "status": "active" }. Resuming clears the failure count and recomputes the next run.
• A task pauses automatically when your credits run out (insufficient_credits) or after 5 consecutive failures (screenshot failures or exhausted webhook retries). Fix the cause, then resume it.
• Use POST /api/v1/schedules/{id}/trigger to fire a run on demand — handy for verifying your webhook end-to-end right after creating a task.
• Poll GET /api/v1/schedules/{id}/runs to inspect run status and delivery errors when debugging.

Batch Screenshots API

Batch jobs let you submit up to 50 URLs at once. Up to three URLs render concurrently in a background queue and, when the whole batch finishes, successful captures are packaged into a ZIP archive (with a manifest.json listing every URL and its result). You can either provide a webhookUrl to be notified on completion, or poll the job status. The feature is available on the Starter plan (up to 3 concurrent batches) and the Pro plan (up to 5); each successful capture consumes the same credits as a regular screenshot and failed URLs are not charged.

Endpoints

Submit a batch

POST /api/v1/batch accepts a JSON body. Every entry must already be a valid http(s) URL — entries with surrounding whitespace or blank entries are rejected with 400. Duplicates are removed and order is preserved:

{
  "name": "Competitor homepage audit",
  "urls": [
    "https://example.com",
    "https://example.org",
    "https://example.net/pricing"
  ],
  "webhookUrl": "https://your.app/hooks/snapapi",
  "options": { "fullPage": true, "format": "png" }
}

The create response (201) returns the job object with status: "queued", a total count, and — when a webhook URL was supplied — a per-job webhookSecret (prefixed whsec_) used to verify deliveries. Submitting as a FREE account returns 403; exceeding the concurrent-batch quota returns 403; insufficient credits for the estimated batch cost returns 402.

curl -X POST https://snapapi.top/api/v1/batch \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "urls": ["https://example.com", "https://example.org"],
    "webhookUrl": "https://your.app/hooks/snapapi"
  }'

Polling job status

GET /api/v1/batch/{id} returns the job, its items, and (once ready) zipUrl. Job status moves through queued → running → packaging → delivering → completed (or failed); a poll-only job with no webhookUrl skips delivering and completes straight from packaging. Each item reports pending, running, succeeded, or failed with an error message on failure. A 5-second poll interval is recommended while the job is active:

{
  "ok": true,
  "batch": {
    "id": "b1e2c3d4-…",
    "name": "Competitor homepage audit",
    "status": "completed",
    "total": 3,
    "succeeded": 2,
    "failed": 1,
    "zipKey": "batch/2026/08/31/uuid.zip",
    "zipBytes": 482130,
    "createdAt": "2026-08-31T09:00:00.000Z",
    "finishedAt": "2026-08-31T09:00:42.000Z"
  },
  "items": [
    { "index": 1, "url": "https://example.com", "status": "succeeded", "bytes": 210432, "error": null },
    { "index": 2, "url": "https://example.org", "status": "succeeded", "bytes": 271698, "error": null },
    { "index": 3, "url": "https://example.net/pricing", "status": "failed", "bytes": null, "error": "net::ERR_NAME_NOT_RESOLVED" }
  ],
  "zipUrl": "https://snapapi.top/api/v1/files/…"
}

Response wrapping: create (201) returns { ok: true, batch: { … } }; list returns { ok: true, batches: [ … ] } (newest first, with webhookSecret omitted); detail returns the shape above — { ok, batch, items, zipUrl }. The batch job object:

Each entry in items:

Webhook notification

When packaging finishes, SnapAPI POSTs a batch.completed event to your webhook URL, signed exactly like scheduled-task deliveries (X-SnapAPI-Signature: sha256=<HMAC> keyed with the job's webhookSecret; verify with the same timing-safe comparison shown in the Scheduled Screenshots section). Failed deliveries retry after 1, 5, and 30 minutes. The zipUrl is null if every URL failed (no archive is produced):

{
  "event": "batch.completed",
  "batchId": "b1e2c3d4-…",
  "name": "Competitor homepage audit",
  "total": 3,
  "succeeded": 2,
  "failed": 1,
  "zipUrl": "https://snapapi.top/api/v1/files/…",
  "zipBytes": 482130,
  "createdAt": "2026-08-31T09:00:00.000Z",
  "finishedAt": "2026-08-31T09:00:42.000Z",
  "timestamp": "2026-08-31T09:00:42.500Z"
}

Webhook payload fields:

ZIP archive contents

• manifest.json — the first entry: batch id, totals, and a per-URL record (index, url, status, file name, bytes, duration, error).
• One image per successful capture, named NNN-hostname.ext with the 1-based submission index (for example 001-example.com.png), so file order matches your input order.
• The zipUrl link needs no API key and stays valid for 7 days; archives are deleted afterwards.

Visual Diff API

POST /api/v1/diff compares two images at the pixel level (decoded with sharp, matched with pixelmatch) and reports how much changed. It is available on the Starter and Pro plans (FREE returns 403). Provide a baseline image and choose how to supply the current one:

• Image vs image — set currentImageUrl to another image URL. Both images are downloaded and compared; this costs one diff credit.
• Image vs live page — set url instead. SnapAPI captures the page live (always PNG) and compares it against the baseline; this costs one screenshot credit plus one diff credit.
• Upload files — send multipart/form-data with baseline and/or current file fields. Uploads mix freely with URLs and live captures (e.g. an uploaded baseline plus url); this costs one diff credit, plus one screenshot credit when using url.

External image URLs pass through SSRF protection; an unreachable URL, a non-image response, or an undecodable image returns 422. With JSON, exactly one of currentImageUrl or url is required; with multipart, provide exactly one of current, currentImageUrl, or url, and exactly one of baseline or baselineImageUrl.

Uploaded files accept multipart/form-data only: each file is capped at 25 MiB and the whole request at ~52 MiB (oversize returns 413); an unsupported Content-Type returns 415; a file with an explicitly non-image type (e.g. text/plain) or a malformed field returns 400. Files with no type or application/octet-stream are accepted and decoded by sharp, returning 422 when the bytes are not a real image. Scalar options are sent as text fields (numbers as numeric strings, booleans as "true"/"false").

Set produceDiffImage to true to receive a side-by-side JPEG: the baseline image on the left and the current image on the right, with changed regions marked by red boxes on the right half. It is returned as a 15-minute signed URL (diffImage.url) you can open directly or download; no extra credit is charged. The image is always produced when requested, even when nothing changed (a side-by-side image with no red boxes).

curl -X POST https://snapapi.top/api/v1/diff \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "baselineImageUrl": "https://cdn.example.com/home/baseline.png",
    "url": "https://example.com",
    "threshold": 0.01,
    "produceDiffImage": true,
    "fullPage": true
  }'

Uploading image files uses multipart form fields (files and URLs may be mixed):

# both images uploaded
curl -X POST https://snapapi.top/api/v1/diff \
  -H "Authorization: Bearer snap_your_api_key" \
  -F "baseline=@/path/to/baseline.png" \
  -F "current=@/path/to/current.png" \
  -F "threshold=0.01" \
  -F "produceDiffImage=true"

# uploaded baseline compared against a live page capture
curl -X POST https://snapapi.top/api/v1/diff \
  -H "Authorization: Bearer snap_your_api_key" \
  -F "baseline=@/path/to/baseline.png" \
  -F "url=https://example.com" \
  -F "fullPage=true"

A successful response looks like this:

{
  "ok": true,
  "threshold": 0.01,
  "changePercentage": 0.0231,
  "changePercent": 2.31,
  "hasChanged": true,
  "diffPixels": 36210,
  "totalPixels": 1568000,
  "width": 1280,
  "height": 1225,
  "diffImage": {
    "url": "https://snapapi.top/api/v1/files/eyJ…signature",
    "contentType": "image/jpeg",
    "bytes": 183420,
    "expiresInSeconds": 900
  },
  "baseline": { "source": "url", "bytes": 201432, "contentType": "image/png" },
  "current": { "source": "capture", "bytes": 207880, "contentType": "image/png", "durationMs": 1180 },
  "creditsUsed": 2
}

The same comparison is available to AI assistants through the MCP diff_pages tool, which captures both pages and compares them in one call; pass includeDiffImage to get the side-by-side comparison image (red boxes on changes) as a 15-minute signed URL (diffImageUrl).

Visual Monitors API

A monitor captures a URL on a recurring cron schedule (UTC), compares each capture against a saved baseline at the pixel level, and — when the changed-pixel ratio meets your threshold — sends a signed monitor.changed alert to your webhook with links to the baseline, current, and diff images. Monitors are available on the Pro plan (up to 10 monitorsper account; other plans return 403). Each run performs one screenshot plus one comparison, so it consumes one screenshot credit and one diff credit; failed runs are not charged.

How baselines work

The first run establishes the baseline and never alerts. After that, the baselineMode decides when the reference image moves forward:

• fixed (default) — the baseline never changes; every run is compared against the original. Best for detecting any drift from a known-good state.
• auto (rolling) — each capture becomes the new baseline, so you are alerted only about changes since the previous run.
• manual — the baseline stays fixed until you confirm a new one from the dashboard.

Endpoints

Create a monitor

POST /api/v1/monitors accepts a JSON body:

{
  "name": "Marketing homepage",
  "url": "https://example.com",
  "cron": "0 */6 * * *",
  "webhookUrl": "https://your.app/hooks/snapapi",
  "baselineMode": "fixed",
  "threshold": 0.01,
  "options": { "fullPage": true, "width": 1280 }
}

The create response (201) returns { ok: true, monitor: { … } }, including a per-monitor webhookSecret (prefixed whsec_) when a webhook URL was supplied. The list endpoint returns { ok: true, monitors: [ … ] } (newest first, secret omitted); detail returns { ok: true, monitor }. The monitor object:

POST …/{id}/trigger returns 202 with { ok: true, runId } to run a comparison immediately. GET …/{id}/runs returns { ok: true, runs: [ … ] } (50 most recent). Each run object:

Change-alert webhooks

When a run detects a change past the threshold (or fails), SnapAPI POSTs an event to your webhookUrl, signed exactly like scheduled-task deliveries — X-SnapAPI-Signature: sha256=<HMAC> keyed with the monitor's webhookSecret; verify it with the same timing-safe comparison shown in the Scheduled Screenshots section. The X-SnapAPI-Event header is monitor.changed or monitor.failed. Failed deliveries retry after 1, 5, and 30 minutes.

{
  "event": "monitor.changed",
  "taskId": "m3n4o5p6-…",
  "runId": "r9f8e7d6-…",
  "url": "https://example.com",
  "baselineUrl": "https://snapapi.top/api/v1/files/…",
  "currentUrl": "https://snapapi.top/api/v1/files/…",
  "diffUrl": "https://snapapi.top/api/v1/files/…",
  "changePercentage": 0.0231,
  "changePercent": 2.31,
  "hasChanged": true,
  "threshold": 0.01,
  "baselineUpdated": false,
  "durationMs": 1340,
  "error": null,
  "timestamp": "2026-09-06T06:00:02.100Z"
}

The image links need no API key and stay valid for 7 days. On monitor.failed, currentUrl and diffUrl are null; baselineUrl is still signed and returned when the monitor already has a baseline (it is null only when a failure happens before the first baseline exists). The threshold and durationMs fields are also populated on failure. Run history and comparison images are retained for 90 days on the Pro plan. Payload fields:

Pausing, resuming, and failures

• Pause with PATCH /api/v1/monitors/{id} and body { "status": "paused" }; resume with { "status": "active" }. Resuming clears the failure count and recomputes the next run.
• A monitor pauses automatically when your credits run out (insufficient_credits) or after 5 consecutive failures. Fix the cause, then resume it.
• Monitors run entirely on platform storage so comparisons stay fast and reliable — connecting your own cloud bucket (below) does not move monitor baselines or images.

Cloud Storage Delivery

On the Pro plan you can deliver captures directly to your own cloud bucket — Amazon S3 or Cloudflare R2 (any S3-compatible endpoint) — instead of downloading them through SnapAPI. Configure the provider, bucket, region/endpoint, and access credentials in the dashboard; the secret key is encrypted with AES-256-GCM before storage and is never returned by the API (the access key ID is shown so you can identify the configured credential).

Once a bucket is connected:

• Synchronous screenshots and scroll videos (response: "json") are written straight to your bucket. The response reports storage: "s3" with the bucket and key (plus region, endpoint, provider) so you can locate the object; the platform-signed url is null in this case. Objects are stored under <keyPrefix>/<yyyy>/<mm>/<dd>/<uuid>.<ext> — snapapi/… by default (the prefix is customizable in the dashboard), with scheduled/ and batch/ sub-prefixes for those deliveries.
• Scheduled screenshots and batch ZIP archives are uploaded directly to your bucket, and the screenshotUrl / zipUrl in webhook payloads are presigned links against your own bucket (valid for 7 days) — downloads never transit the platform.
• Monitors keep using platform storage: the baseline is a server-side working set that is read back on every comparison, so monitor images are not written to your bucket.

If an upload to your bucket fails (bad credentials, missing permission, or wrong bucket name), the call returns 422 with a clear error and does not fall back to platform storage — so you never mistake a missing object for a successful delivery. Synchronous calls that fail this way are not charged; async runs are marked failed. Disconnecting or changing the bucket in the dashboard affects new captures only; already-delivered objects stay in whatever bucket they were written to.

Errors

Errors return JSON with an error message:

{ "ok": false, "error": "insufficient credits" }

Code examples

cURL

curl -X POST https://snapapi.top/api/v1/screenshot \
  -H "Authorization: Bearer snap_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "fullPage": true,
    "format": "jpeg",
    "quality": 80,
    "dark": true
  }'

JavaScript (fetch)

const res = await fetch("https://snapapi.top/api/v1/screenshot", {
  method: "POST",
  headers: {
    "Authorization": "Bearer snap_your_api_key",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    url: "https://example.com",
    fullPage: true,
    format: "png",
  }),
});

const data = await res.json();
console.log(data.url); // temporary link to the screenshot

Python (requests)

import requests

res = requests.post(
    "https://snapapi.top/api/v1/screenshot",
    headers={"Authorization": "Bearer snap_your_api_key"},
    json={
        "url": "https://example.com",
        "fullPage": True,
        "format": "png",
    },
)
res.raise_for_status()
print(res.json()["url"])

MCP Server

SnapAPI speaks the Model Context Protocol (MCP), so AI assistants can call it as a tool. Connect any MCP-compatible client to the endpoint below using the same Bearer API key:

https://snapapi.top/api/mcp

Tools

Claude Desktop

Add the server to your claude_desktop_config.json:

{
  "mcpServers": {
    "snapapi": {
      "url": "https://snapapi.top/api/mcp",
      "headers": {
        "Authorization": "Bearer snap_your_api_key"
      }
    }
  }
}

Cursor & other clients

In Cursor, add a new MCP server using the streamable-HTTP / HTTP transport with the URL and Authorization header above. Other MCP-compatible clients work the same way.

Once connected, just ask your agent — for example, “take a full-page screenshot of example.com in dark mode” — and it will call the tool for you.