How Screenshot API Credit Limits Work
Learn how screenshot API credits, quotas, rate limits, resets, failures and overages work, with provider examples and practical monitoring guidance.
Screenshot API credit limits are provider-specific. “Credits” may mean a monthly allowance, a daily cap, prepaid credits, a request-rate limit, or several of these at once. Before integrating an API, check five details: what event is metered, when the allowance resets, whether failures and cache hits count, what happens at exhaustion, and how remaining usage is exposed.
What a screenshot API credit limit can mean
These terms are often mixed together, but they control different things:
| Term | Meaning | Typical question |
|---|---|---|
| Included allowance | Captures included with a free or paid plan for a defined period. | Does it reset monthly, daily or on my billing anniversary? |
| Purchased credit balance | A separate pool bought in advance or added as a top-up. | Does it expire, and is it used before or after the plan allowance? |
| Request-rate limit | The maximum request speed, such as requests per minute. | Can I still be throttled while unused monthly credits remain? |
| Overage | Usage beyond the included allowance that is billed separately. | Will requests continue, or will the API stop them? |
One request is not automatically one billable credit. A provider may meter successful captures, final exported images, batch items, or another unit. Read the provider’s current documentation before forecasting spend.
Direct answers to common credit questions
What happens when I run out?
The service may return HTTP 402, return HTTP 429, permit paid overage, require a top-up, or wait until the next reset. A 429 can mean either throttling or an exhausted daily/monthly quota, depending on the provider. Inspect the response body and documentation instead of retrying blindly.
Do credits reset every month?
Some allowances reset monthly, some reset daily, and some reset at the subscription anniversary. Purchased packs may follow different expiry rules. For example, ScreenshotAPI documents a billing-period reset for included allowance and says its purchased credit packs do not expire; those are ScreenshotAPI policies, not industry defaults. Read its endpoint and quota documentation.
Does a failed screenshot consume a credit?
There is no universal answer. ScreenshotAPI says failed requests are not charged and cached responses do not count against its monthly allowance. ScreenshotAPI.com says failures caused by a server interruption or webpage load failure are not credited against quota. Confirm the exact rule for the service you use.
Is a rate limit the same as a monthly quota?
No. A rate limit controls how quickly requests arrive. A quota controls how many captures are available during a period. You can have thousands of credits left and still receive a rate-limit response.
How do I check remaining credits?
Use the provider’s balance endpoint, dashboard, response headers, or transaction history. ScreenshotAPI documents an x-credits-remaining response header plus balance, credit-pack and transaction endpoints. See its credits API.
Provider examples
ScreenshotAPI (screenshotapi.to)
Its documented order is one successful capture from the plan allowance first, then purchased credit packs. When both are empty, the API returns HTTP 402 and does not process the request. Its endpoint documentation says included allowance resets at the plan billing boundary: the first of the month for free accounts and the subscription anniversary for paid accounts. Its pricing page lists current plan quantities, overage rates and non-expiring credit packs; recheck those volatile terms before publishing or budgeting. Pricing and credit-pack terms.
ScreenshotAPI.com
This service describes metered pay-as-you-go billing where a successful image capture counts as a screenshot. Its pricing FAQ says server interruptions and webpage-load failures do not consume quota. Review its current billing page.
ShotAPI
ShotAPI presents daily limits rather than a monthly credit-pack model in its pricing materials: the listed examples are 100 captures per day on Free, 2,500 on Starter and 10,000 on Pro. Its FAQ says the exhausted daily limit returns HTTP 429 and becomes available again at midnight UTC. Plan numbers can change. Check the current limits.
screenshot-api.org
Its documentation separates a request-rate limit from a monthly screenshot quota. The free-tier examples shown are 60 requests per minute and 500 screenshots per month, with separate 429 errors for rate and quota conditions. Verify the live plan before relying on those figures. Read the API reference.
app screenshotAPI
This adjacent service meters app-store screenshot exports rather than general webpage captures. Its documentation describes HTTP 402 when a key runs out and counts final exported images in multi-canvas, multi-locale workflows. It illustrates why “one request equals one credit” cannot be assumed across products. See its pricing and API reference.
What to compare before choosing a service
- Metering unit: request, successful screenshot, page, batch item or final exported image.
- Allowance period: per second/minute, per day, calendar month or billing cycle.
- Exhaustion behavior: 402, 429, a reset wait, overage, automatic top-up or manual purchase.
- Carryover: whether unused allowance rolls forward and whether purchased credits expire.
- Failure and cache policy: treatment of timeouts, retries, bot checks, failed loads and cached responses.
- Observability: remaining-credit headers, balance endpoint, reset timestamp, dashboard and transaction log.
- Cost predictability: included captures, overage price and expected concurrency.
Forecast your monthly usage
Start with:
monthly_captures = unique_urls * captures_per_url_per_monthThen add scheduled retries, responsive or dark-mode variants, PDF jobs and batch items. Subtract cache hits only when the provider explicitly says they are free. Compare the result with both the allowance and the request-rate ceiling.
| Workload | Calculation to record |
|---|---|
| Monitoring 200 URLs daily | 200 × 30 = 6,000 capture attempts per month |
| Three viewport variants | Base captures × 3 |
| Retry policy | Add the maximum or expected retry count |
| Batch endpoint | Check whether billing is per call or per URL in the batch |
Keep a safety margin for launch spikes. A quota forecast that ignores retries and burst limits will understate both cost and completion time.
Handling exhausted-credit and rate-limit responses
- Read the status code and structured response fields.
- Classify the failure as quota exhaustion, request throttling, authentication, or page failure.
- For a hard quota error, stop tight-loop retries and notify the account owner.
- For throttling, reduce concurrency, honor
Retry-Afteror provider guidance, and use exponential backoff. - Record the reset timestamp and resume only when the documented window opens or the balance changes.
On ScreenshotAPI, the documented 402 response includes remaining plan amount, credit balance, quota reset timestamp and an upgrade URL. Build your worker around those fields when available instead of parsing human-readable prose.
Runnable monitoring pattern
Preserve response headers and status codes in your own usage log. A minimal shell check looks like this:
curl -i -G 'https://api.example.com/screenshot' \
--data-urlencode 'url=https://example.com' \
-o shot.png
# Inspect HTTP status, quota headers and any reset timestamp.For production jobs, store one record per attempt with the URL, provider, HTTP status, billed/failed result, response request ID, retry count and observed remaining balance. Alert before the balance reaches zero.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. It removes cookie and consent banners, newsletter popups and chat widgets before capture; bot checks, blank pages, timeouts, failed loads and cache hits are not billed. Each response reports the result with X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients.
Use the API directly (see the ScreenshotNeo documentation):
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport 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}`);ScreenshotNeo supports full-page and element captures, lazy-image loading, device presets or custom viewports, dark mode, retina scale, PDFs, HTML/CSS rendering, custom CSS and JavaScript, clicks, waits, blocking rules, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, configurable caching, signed links, async webhooks, bulk capture of up to 100 URLs per call and usage reporting. Every feature is on every plan: 1,000 shots/month free with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.
Troubleshooting checklist
| Symptom | Likely cause | Fix |
|---|---|---|
| HTTP 402 | Included allowance and purchased balance are exhausted. | Check balance and reset time; pause work or add authorized credits. |
| HTTP 429 immediately | Daily/monthly quota or request-rate limit. | Inspect the body and headers, then wait for reset or lower concurrency. |
| Credits disappear faster than expected | Retries, variants or batch items are metered separately. | Log every attempt and verify the provider’s metering unit. |
| Failed pages are charged | Provider counts attempts or has different failure rules. | Read billing terms; do not assume another provider’s policy applies. |
| Usage appears stale | Dashboard or balance endpoint is delayed. | Use response headers and transaction history where documented. |
| Requests succeed slowly | Concurrency exceeds the rate limit or pages are heavy. | Use a queue, bounded workers, backoff and caching. |
Performance, reliability and cost practices
- Use a bounded queue instead of unbounded parallel requests.
- Cache deterministic captures when the provider supports a configurable TTL.
- Separate quota errors from transient network and webpage errors in metrics.
- Make retries idempotent and cap attempts so an outage cannot consume the whole allowance.
- Schedule large batches away from reset boundaries and monitor the reset timestamp.
- Keep a per-provider cost model because failure, cache and overage rules differ.
FAQ
Can I compare two providers by their headline credit count?
Only after normalizing period, metering unit, cache treatment, failure policy, overage and rate limits.
Should my client retry every 429?
No. First determine whether it is throttling or quota exhaustion. Back off for throttling; stop and wait for reset or an authorized balance change for quota exhaustion.
Are free-tier numbers permanent?
No. Plan quantities and billing terms are vendor policies that can change. Recheck the linked pricing page before publishing or committing spend.
What is the safest usage metric?
Track attempts, successful captures, billed captures, failures, cache hits, status codes and remaining balance separately.
