How to Limit Screenshot API Requests per Minute in Make

To limit screenshot API requests per minute in Make, set “Maximum runs to start per minute” for an instant scenario. Open the lightning settings on the instant trigger or the scenario’s Schedule setting. Choose a rate below the screenshot provider’s quota. Make does not define one universal per-minute quota for third-party screenshot APIs, so check the provider’s current limit and your account plan before choosing a number.

For scheduled scenarios, spread work across more runs by lengthening the schedule interval or reducing the number of records processed in each run. If each run makes multiple screenshot requests, account for all of them when setting your pace.

1. Identify which service is enforcing the limit

A 429 response usually indicates that the screenshot API has received too many requests for its current limit. Make describes its RateLimitError as corresponding to HTTP 429, while noting that third-party apps may not always use that convention. Check the screenshot provider’s response and documentation to confirm what the error means and when its limit resets.

Make’s organization-plan limits for the Make API concern calls to Make’s own API. They do not automatically limit HTTP requests your scenario sends to a separate screenshot provider. Make lists API limits of 60 requests per minute for Core, 120 for Pro, 240 for Teams, and 1,000 for Enterprise; these are Make API limits, not screenshot capture quotas. Confirm current plan details in Make’s documentation.

What you see	Likely limit owner	What to check
429 returned by the screenshot endpoint	Screenshot provider	Provider quota, endpoint-specific rules, account plan, reset information, and other workloads sharing the account
Error calling Make’s API	Make API	Organization plan and the Make API’s current limit documentation
Scenario runs queue or start too quickly	Make scenario scheduling	Instant-trigger run-start setting, schedule interval, and concurrent scenario activity

2. Limit instant-trigger scenario starts

Open the scenario in Make and identify the instant trigger, such as a webhook.
Open the trigger’s lightning settings, or open the Schedule setting in the scenario toolbar.
Find Maximum runs to start per minute and set a conservative value below the provider’s allowed request rate.
Save the scenario and observe the provider’s response and Make’s execution history as traffic arrives.

Make says incoming requests beyond the configured rate are queued for gradual processing. This setting controls how frequently scenario runs begin; it does not promise an exact interval between every HTTP request inside a run.

Choose a safe rate for your scenario

First find the provider’s quota for the exact endpoint and account plan. Then estimate how many screenshot requests each scenario run sends. If a run makes one capture, the run-start limit can be set below the provider’s per-minute allowance, leaving room for other scenarios and manual requests. If each run makes several captures, use this practical estimate:

scenario starts per minute ≤ safe provider requests per minute ÷ captures per scenario run

This is a planning calculation, not a Make guarantee. Reduce the result further when other scenarios or users share the provider account, or when a run can retry requests. If the provider documents separate burst and sustained limits, account for both.

3. Pace scheduled scenarios and batches

For scheduled work, reduce how much work each run does or increase the time between runs:

Lengthen the schedule interval when the captures do not need to finish immediately.
Reduce the module’s record limit so each run makes fewer captures.
Spread a large backlog across multiple runs instead of processing it at once.
Where the destination supports it, use a bulk action to send multiple items in fewer API requests.

Make recommends processing up to 20 records per run as one strategy for frequent scheduled runs. Treat that as Make guidance, not as a quota or guarantee from your screenshot provider. Check how many external requests the selected module actually makes for each record.

Instant triggers versus scheduled work

Choose this approach	When it fits	Watch for
Limit instant scenario starts	Events need prompt processing, but incoming traffic arrives in bursts	One run may make several API calls, and other scenarios may share the quota
Lengthen the schedule interval	Work can wait and a steady pace is more important than immediate results	A longer interval increases completion time for a backlog
Lower records per run	Scheduled runs process lists or bundles of URLs	More runs may be needed to clear the same volume

4. Reduce unnecessary requests before adding delays

Look for repeated captures of the same URL, duplicate trigger events, or scenario branches that make a screenshot even when no downstream step needs it. Make documents bulk actions and aggregators as ways to reduce requests. Use them only when they match the destination module’s behavior and the data you need.

If your screenshot provider supports caching, verify its cache behavior and whether a cache hit still counts against its quota. Do not assume that caching is available or that it reduces billed requests without checking the provider’s terms.

5. Use delays, sequential processing, and retries carefully

Make’s Sleep module can pause processing for up to 300 seconds. Make’s help guidance gives an example of an API limited to 10 requests per minute, using a six-second delay between requests. That is an illustration for that example quota, not a universal screenshot API setting.

A delay can help when you know the provider’s quota and reset behavior, but placing a Sleep module in a scenario does not necessarily prevent parallel runs or requests from other scenarios. Make cautions that Sleep can delay bursts rather than fix their cause. Prefer controlling scenario starts or batch size when those are the source of the burst.

Make also documents sequential processing: a scenario waits for an active run to finish before starting another. This can reduce overlapping work from instant executions, at the cost of slower throughput. Make notes that errors involving incomplete executions can pause processing, so monitor the scenario and handle failed executions deliberately.

For persistent 429 errors, inspect the provider’s response and current API documentation before choosing a retry delay. Incomplete executions can retry rate-limited work with gradually increasing intervals. Do not assume Make honors a provider-specific retry header unless that behavior is documented for the integration you use.

6. Configure a native screenshot integration or HTTP request

Make lists a verified GetScreenshot integration with actions for page screenshots, element screenshots, and API usage. If you use that integration, check its usage action and its own documentation for quota and error behavior. Its limits do not establish the limits of other screenshot providers.

For a generic HTTP module, send the request to your provider’s documented endpoint and pass authentication and capture parameters as that provider specifies. Store credentials in Make’s supported connection or secret fields rather than exposing them in URLs or execution data where possible. The title does not identify a provider, so a provider-specific request URL, API key format, or exact request-per-minute value cannot be supplied here.

7. Troubleshoot common rate-limit problems

Problem	Likely cause	Fix
Screenshot request returns 429	The provider’s quota was exceeded, possibly by another scenario using the same account	Check provider quota and reset guidance; lower the scenario start rate or batch size; inspect other workloads sharing the account
429 continues after lowering the Make limit	Each run makes multiple captures, concurrent or scheduled work also sends requests, or the provider applies a burst limit	Count requests per run and across scenarios; lower the rate further; use the provider’s documented reset or retry guidance
Requests still arrive in bursts after adding Sleep	Several scenario runs may execute at once, or the delay is inside each run rather than controlling starts	Set the maximum runs to start per minute, consider sequential processing, and reduce batch size
Scheduled scenario takes too long to clear work	The interval or per-run record limit is too restrictive for the backlog	Estimate the completion time against the provider quota and raise batch size or frequency only within the documented limit
Make API limit figures do not resolve screenshot 429s	Make API limits were mistaken for a third-party provider’s endpoint quota	Use the screenshot provider’s quota documentation for requests sent to that provider
Retries create another burst	Several failed executions retry near the same time, or the retry interval does not match the provider’s reset window	Use gradual retry intervals and provider guidance; avoid launching a large backlog of retries at once

8. Performance, reliability, and cost considerations

Throughput: a lower start rate reduces burst pressure but can increase queue time and backlog completion time. Estimate volume using runs per minute multiplied by captures per run.
Reliability: leave headroom for retries and other workflows that share the account. Monitor both Make execution errors and provider responses; a successful scenario start does not guarantee a successful capture.
Cost: check how the provider counts successful captures, failed requests, retries, cache hits, and bulk operations. Do not infer billing behavior from Make’s run limits.
Concurrency: sequential processing can smooth overlapping instant runs, while independent scenarios may still contribute traffic to the same provider quota.

Or skip the browser setup

If you want a screenshot endpoint without managing a browser, ScreenshotNeo is a website screenshot API and MCP server. Make a GET request with a URL to receive a PNG, JPEG, WebP, or PDF. 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

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)

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

Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers report the page verdict and billing status.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
The free plan includes 1,000 shots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is available on every plan.

FAQ

Does Make have one default limit for screenshot API calls?

No. The safe rate depends on the provider, endpoint, account plan, and how many requests each scenario run makes.

Does “Maximum runs to start per minute” space out every request?

No. It limits scenario starts. A single run can make multiple requests, and separate scenarios can also use the same provider account.

Should I use Make’s API plan limits to set my screenshot rate?

No. Those figures apply to calls to Make’s API, not automatically to requests sent from Make to a screenshot service.