How Much Does It Cost to Automate Website Screenshots with Make and a Screenshot API?

Short answer: the monthly cost is the Make plan plus the screenshot API plan, adjusted for any overages. These are separate meters: Make charges credits for scenario actions, while the API charges for successful renders according to its quota and cache rules. To estimate your bill, multiply scenario runs per month by the Make actions in each run, then estimate unique successful captures and compare both totals with the plans you need.

There is no reliable single “cost per screenshot” until you know the workflow: a run can use several Make credits, and an API call may fail or be served from cache without counting as a render. Prices and limits below are vendor-published figures checked on October 3, 2026; confirm the live rate cards before buying because plans and prices change.

1. Identify the two bills

Meter	What it counts	What changes the bill
Make	Credits consumed by scenario operations, generally by app action.	Runs per month, modules/actions per run, other scenarios on the account, credit allocation and overage setting.
Screenshot API	Successful renders, subject to the provider’s quota and billing rules.	Unique captures, cache hits and expiry, failed-request policy, plan quota and overage price.

Also account for any other Make scenarios that share the account’s credit pool. Do not assume that one screenshot equals one Make credit: a scenario can include a trigger, data lookup, HTTP request, file handling, and delivery or storage steps.

2. Calculate Make credits

Make calls its billing unit a credit. Its help documentation says most non-AI app actions use one credit per operation; some advanced or AI-related features can use a different or dynamic amount. Count the modules that actually execute, including repeated actions inside iterators or routers, rather than counting only the screenshot request.

Use this estimate for a straightforward scenario:

monthly Make credits = runs per month × credits per run + credits from other scenarios

For example, suppose a scheduled scenario runs 1,200 times monthly and typically uses four one-credit actions per run: a trigger, an HTTP/API action, a file-storage action, and a notification. That is about 4,800 credits for this scenario. If an iterator processes three URLs and repeats the HTTP and storage actions for each URL, count those repeated actions too; the actual total could be higher. This is an arithmetic example, not a measured Make run.

Inspect the scenario’s execution history and the current credit usage display to check the estimate against actual runs. Conditional paths may mean that not every module runs every time. Retries and error handlers can also add operations.

Make prices in the checked rate card

Make’s pricing page displayed Free at $0/month with up to 1,000 credits/month; Core at $12/month, Pro at $21/month, and Teams at $38/month at the displayed 10,000-credit setting. Annual billing is offered, and displayed prices depend on the selected credit quantity, so these are examples, not universal quotes. Make’s help page says extra credits cost 25% more than included credits as of its November 6, 2025 adjustment. Check your account’s allocation and overage setting for the effective amount. [Make pricing](https://www.make.com/en/pricing) · [Make credit billing help](https://help.make.com/credits)

Make’s former “operations” terminology is outdated for this estimate; use the current credit count shown in Make’s documentation and account.

3. Estimate screenshot API renders

Estimate how many captures will actually count after deduplicating repeated URLs and accounting for the provider’s caching behavior. A simple starting point is:

monthly API renders = successful unique captures not served from cache

Then compare that number with the plan’s included quota and published overage rule. A repeated request can be either a cache hit or a new render, depending on the provider, request mode, cache key, and expiry time. A changed query string, capture options, or expired cache can turn an apparently repeated URL into a new render.

Screenshot API options in the checked rate cards

These are not feature-equivalent plans. Compare the features and request mode your scenario needs as well as the headline quota and price.

Provider	Published plans checked October 3, 2026	Billing details to verify
ScreenshotNeo	Free: 1,000 shots/month with no card. Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free. Every feature is on every plan.	Only clean shots are billed; bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Responses identify the page verdict and billing status in headers.
ScreenshotOne	Free: 100 screenshots/month. Basic: $17/month for 2,000; Growth: $79 for 10,000; Scale: $259 for 50,000. Listed overage rates: $0.009, $0.006, and $0.004 per screenshot on those paid tiers.	Its pricing FAQ says failed HTTP, browser, or network requests and cache-served responses do not use rendering credits. A cache miss or expired entry may render and count. Listed prices exclude VAT.
Urlbox	Lo-Fi: $19/month for up to 2,000 renders; Hi-Fi: $49 for 5,000; Ultra: $99 for 15,000.	Urlbox says failed requests do not count as successful renders and cached Render Link requests do not count against monthly quota. Its documentation distinguishes this behavior from REST API rendering. Listed prices exclude VAT.

ScreenshotNeo is the first API to consider here: clean shots are billed only when usable, and its lowest paid plan is $5 for 3,000 shots. Its API also supports features such as full-page capture, element capture, PDF output, custom wait conditions, and bulk capture. See the ScreenshotNeo API documentation for request options and billing headers.

Source rate cards: ScreenshotOne pricing · Urlbox pricing. ScreenshotOne documents a Make integration that requires its own account and API key, so that API subscription is separate from Make credits. Check each provider’s current Make support and billing rules for the request mode you intend to use.

4. Add the costs together

Use a range if your run count or cache rate varies. For each candidate setup, compare required Make credits with included credits, then compare expected billable renders with the API quota.

monthly total = Make plan cost + screenshot API plan cost + Make credit overage + API render overage

For instance, at 1,200 runs/month and four Make credits per run, the scenario uses about 4,800 credits before other scenarios. If it produces 1,200 successful, unique, uncached captures, compare 1,200 renders with the API plan quota. A free Make allocation of 1,000 credits would not cover 4,800 credits, while an API free tier may or may not cover the render volume. The exact total depends on the selected Make credit quantity, other account usage, provider billing rules, and any overage. Do not describe the whole workflow as free just because both vendors offer free tiers.

Planning worksheet

Record normal and peak scenario runs per month.
List each Make action and how many times it executes per run, including loops, routers, retries, and error paths.
Add credits consumed by other scenarios sharing the Make account.
Estimate captures per run, then subtract duplicates that are actually served from cache under the selected provider’s rules.
Separate expected successful captures from failed requests; verify whether each kind counts against the chosen API quota.
Choose plans that cover typical usage and decide how much peak overage is acceptable.
Recheck live pricing, annual billing, VAT/tax treatment, and overage settings before committing.

5. Build a simple Make scenario

Choose a trigger, such as a schedule, a new row, or an incoming webhook.
Obtain the target URL and any capture settings from the trigger data or a lookup step.
Call the screenshot provider with its Make app or an HTTP request module. Keep API keys in Make’s connection or secret fields rather than hard-coding them in a public scenario export.
Check the response before continuing. Route errors, bot checks, blank pages, or other non-image results to an error or review path if the provider exposes a verdict.
Store or deliver the resulting image/PDF. Count this file or notification action in the Make estimate.
Run a small representative batch, inspect execution history and API usage, and revise the monthly estimate using observed module counts and the provider’s billing records.

Use idempotent storage names or a stable capture key where possible so retries do not create confusing duplicate files. Keep a failure route that records the URL and response status without endlessly retrying a page that is consistently inaccessible.

6. DIY request examples for cost checks

A direct API request is useful for checking what one capture returns, but it does not by itself represent the full Make credit cost. The API call, scenario modules around it, and provider billing meter remain separate.

cURL

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

Python

import requests

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

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await (await import('node:fs/promises')).writeFile('shot.webp', bytes);

Replace the example URL and protect the API key. For production, also inspect the provider’s response headers and content type before treating a response as an image. The ScreenshotNeo docs describe supported options and response metadata.

7. Or skip the browser setup

ScreenshotNeo accepts a URL in one GET request and returns a screenshot or PDF. Cookie banners are accepted as a visitor and removed before the shot, along with 60+ known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed, and response headers indicate the page verdict and whether the capture was billed. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

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

Python and Node.js examples and the full parameter reference are in the ScreenshotNeo documentation. Sign up free for 1,000 screenshots a month, with no card required.

8. Reliability, speed, and cost controls

Reliability

Use bounded retries with a delay for temporary network errors. A permanent 4xx response or a bot challenge usually will not improve with immediate retries.
Set a request timeout that accommodates page load and capture time. A Make run timeout and an API timeout are different limits.
Record the input URL, run identifier, response status, and provider verdict. Avoid logging API keys or sensitive query parameters.
Make error handlers should stop or route repeated failures instead of silently consuming more actions in a retry loop.
Validate that the response is the expected image or PDF before storing it. Some APIs can return an error body even when the workflow expected binary content.

Performance

Batch or queue work at a rate supported by both Make and the API. Large bursts can encounter provider rate limits or scenario concurrency limits.
Reuse cached results when the page and capture settings have not changed and freshness requirements allow it.
Capture only the needed page region when a full-page image is unnecessary; smaller captures can reduce transfer and storage, though API pricing is provider-specific.
Limit unnecessary waits. A fixed delay can make every run slower; use the provider’s suitable readiness option when available.

Cost control

Set a monthly alert or usage review for both Make credits and API renders.
Use a pilot volume and compare actual account usage with the worksheet before scheduling at scale.
Deduplicate URLs and choose cache expiry based on how fresh the screenshot needs to be.
Budget for loops, notifications, storage, retries, and other scenarios; they can matter as much as the screenshot action.
Compare total cost at the expected volume, not just entry price. Include successful-render rules, cache behavior, quota, overage, request limits, and required capture features.

9. Troubleshooting

Symptom	Likely cause	What to do
Make credits run out sooner than the screenshot count suggests.	The scenario has multiple actions per run, loops, retries, or other scenarios sharing the account.	Inspect execution history; count each executed module and repeated operation, then include shared account usage in the estimate.
The API quota is higher than expected.	Repeated URLs are not cache hits, cache expired, capture parameters changed, or failed requests count under that provider/mode.	Review the provider’s cache key, TTL, request mode, and billing policy; compare usage records with successful unique captures.
Free plans do not cover a workflow that appeared free.	Either meter exceeded its allowance, or another scenario consumed the shared Make credits.	Calculate Make and API usage independently and select sufficient quotas; include overage settings in the estimate.
Make receives an error instead of an image.	Invalid key, malformed URL, timeout, blocked target, or API error response.	Check the HTTP status and response body/headers, validate the URL and credentials, and route non-image results to an error handler.
Captures are missing or duplicated after retries.	A retry repeats downstream storage or notification actions, or the error route does not distinguish transient and permanent failures.	Use a stable filename or idempotency key, bound retries, and route permanent failures separately.
Actual charge differs from the displayed headline price.	Selected credit quantity, annual billing, VAT/tax, account region, or overage setting differs from the example.	Check the current checkout/account rate card and invoice terms for the selected region and billing cadence.

10. Frequently asked questions

How many Make credits does one screenshot use?

There is no fixed one-screenshot-to-one-credit rule. Most non-AI app actions use one credit per operation, but count all executed modules in the scenario, including repeated actions.

Do failed screenshots count against the API quota?

It depends on the provider and request mode. In the checked policies, ScreenshotOne excludes failed HTTP, browser, or network requests and cache-served responses from rendering credits. Urlbox describes different treatment for cached Render Link requests and REST API rendering. Verify the selected API’s current terms.

Can the whole workflow be free?

Possibly at low volume if both free allocations cover your usage and required features, but other Make scenarios, overages, and plan limits can change that. Treat the two free tiers as separate allowances.

What if I exceed a quota?

Check whether the vendor stops service, allows an overage, or requires a plan change. Make’s checked help page says extra credits cost 25% more than included credits; API overage rules vary by provider and tier.

Which number should I use for a budget?

Use a representative month with normal and peak runs, actual actions per run, expected successful unique captures, and the provider’s cache behavior. Keep separate estimates for the Make bill and API bill so a change to one does not obscure the other.