FIELD NOTES / PRACTICAL GUIDE

Handle the unexpected.

A failed request should tell you what to do next. Check the outcome before retrying or changing a source.

STEP 01

401 or 403: check access

For 401, sign in again or check the Bearer API key and whether it was revoked. A 403 can mean unconfirmed email or a rejected request origin. Read the error message and confirm your account or request setup.

STEP 02

402 or 429: check capacity

402 means there are not enough credits for the request. 429 means a rate or concurrency limit was reached. Respect Retry-After where supplied and reduce simultaneous work. Keys share the account’s limits; creating more keys will not increase capacity.

STEP 03

422 or source errors: inspect the page

A 422 response can describe invalid input, a source policy or robots.txt refusal, a failed fetch, or a result below your minimum quality score. Read its message before retrying. For public pages whose text loads with JavaScript, use rendering or Auto Mode where available and review the credit cost. Neither mode bypasses refused sources. The API reference documents supported responses and restrictions.

STEP 04

Interrupted work: reconcile first

A credit can be temporarily reserved while work is running. Maintenance marks interrupted work failed and restores the credit. Check history or collection progress before submitting again. A new successful scrape is charged again. For synchronous retry protection, send Idempotency-Key on the first attempt and reuse it with unchanged inputs within 24 hours; retained results replay without another acquisition charge. For a collection submission retry, reuse the original client_id to avoid creating a duplicate job.

YOUR PRIVACY

Choose what works for you. You can reopen these settings from the footer at any time.