Credits and Limits
Account endpoints
Section titled “Account endpoints”GET /credits is the compatibility summary:
{ "creditBalance": 4850, "concurrency": 5, "fetchConcurrency": 5, "browserConcurrency": 2}creditBalance can be null before first billing. concurrency is the legacy alias for the fetch cap.
Prefer GET /v1/status in new integrations. It adds available/reserved credits, running and pending work by execution class, active batch IDs, enabled crons, and oldest pending age.
Prices
Section titled “Prices”| Action | Credits |
|---|---|
| Prebuilt request | 1 |
| Parser fetch, default proxy | 1 |
| Parser browser, default proxy | 5 |
| Parser fetch, high-quality proxy | 10 |
| Parser browser, high-quality proxy | 25 |
| Database query | 1 |
| Database table dump | 5 |
| Parser/database/cron/workflow CRUD | 0 |
| Body-only parser dry-run | 0 |
A URL-backed parser or workflow test bills the same fetch price as production.
Reservations
Section titled “Reservations”Asynchronous jobs reserve their full expected cost at submission. Available credits are balance minus existing reservations. Each terminal job settles its reservation: attempted upstream work can be billed even when the job ultimately fails; work canceled before starting releases its reservation.
Use an Idempotency-Key (maximum 128 characters, 24-hour lifetime) on parser creation and batch submission so network retries do not duplicate resources or reservations.
Fetch and browser concurrency
Section titled “Fetch and browser concurrency”Fetch and browser jobs use separate capacity pools and account caps. Using a fetch slot does not consume browser capacity. Sync scrape, URL-backed tests, batches, crons, and workflow stages share these counters.
A full pool returns 429. Poll /v1/status and retry with backoff. pending.limit is separate from running concurrency; an over-capacity batch is rejected as a whole.