Billing policy
Exactly which response types cost credits. Simple rule - only successful (2xx) responses are billed.
Billing policy
Only successful (HTTP 2xx) requests cost credits. Everything else is free.
The rule set
| Outcome | Bill? |
|---|---|
| Auth failure (401) | ❌ Free |
| Bad params (400) | ❌ Free |
| Rate limit from us (429) | ❌ Free |
Roadmap param (501 render_js/screenshot) | ❌ Free |
| Target-site timeout or network failure | ❌ Free |
| Target 503 / challenge page detected | ❌ Free |
| Target 302 to login | ❌ Free |
Target returned 404 (404 item_not_found, item delisted) | ❌ Free |
Target served something, extractor found nothing (502 extraction_failed) | ❌ Free |
ID mismatch - requested item A, got item B (502 id_mismatch) | ❌ Free |
| Partial result (core fields present, some optional fields missing) | ✅ Billed |
| Full result | ✅ Billed |
Why so generous?
Because you shouldn’t pay for our failures. When a target site blocks a request, we absorb the infrastructure cost and return a clean error to you. You get what you paid for or you pay nothing.
Our current success rate is ~97 %, and the cost of the failed 3 % is a rounding error on our margins. The simpler rule - “only 2xx costs credits” - is worth more to us in customer trust than the pennies we’d save by billing borderline cases.
Credit cost per request
Any single request (a dedicated endpoint or the Universal Web Scraper API) costs 5 credits. Two opt-in add-ons are reserved for a future release: JavaScript rendering adds +10 credits (15 total) and a screenshot adds +10 credits. The credit unit is just the internal accounting unit: customer-facing pricing is quoted in requests, at $0.90 per 1,000 successful requests on PAYG, and cheaper on subscriptions.
The one edge case worth flagging
If a result returns valid fields but some optional ones are missing (e.g. price: null for an item with multiple format editions, variations: [] for a single-variant product), you’re billed. The response IS the item - nothing is missing because the extractor failed; it’s missing because the site didn’t publish it. A successful 2xx with real data costs 5 credits.
Retries
Our orchestrator handles retries internally - you send one request, we do the work of getting it through. You’re billed at most once per request, only if the final result is a successful 2xx. The number of internal attempts used is surfaced in the Asa-Attempts response header for your own debugging.
Batch billing
Each item in a batch is billed independently. 800/1000 successes at 5 credits each = 4,000 credits charged. Failures in the batch are free. The failure reason is in each item’s error field.
Checking your usage
Every request, successful or not, appears in your dashboard at /app/usage. Failed requests display $0 for Cost and a clear reason code. Use them to debug, not worry.
Versioning
Any change to this billing policy is announced 14 days in advance via email and reflected in both this page and the pricing FAQ simultaneously. In-flight requests are settled under the old policy.
Related
- Core concepts - the credit model
- Error codes - every non-2xx reason, all free
- Pricing - plan limits and PAYG