Skip to main content
Most API errors use this shape:
Use the HTTP status and code, when present, to choose an action. Keep msg for logs and diagnostics. data may contain validation details or information from the browser. Some forwarded browser responses and scraping errors do not include code, and may use detail or error instead. Your error handler should tolerate these shapes and non-JSON responses from a network intermediary. Record the status and x-cloud-tracing-uuid header when available.

Where the failure came from

Read the response first. Most failures fall into one of these: A browser can start, /scrape can return HTTP 200, and the page can still hold a challenge or an empty result, so check the content and not only the status.

Which timeout fired

Retrying

Choose retries by the reported condition rather than the HTTP status alone: A 400 cluster_is_full can be retried; a 429 caused by exhausted traffic quota needs a different response. HTTP status alone cannot distinguish these cases. If a start request times out or loses its connection, its outcome is uncertain. Check active sessions before repeating it. Creating a profile or one-time session is not an idempotent operation, so an automatic retry can create an extra resource.

Request errors

Limit errors

These errors return HTTP 429. Profile API responses include headers for the current request limits and remaining allowance; see Limits.

Errors from the browser

These errors come from the container running your browser. They usually appear during startup, scraping, or cookie requests.

Validation errors

Gateway validation errors return 422 validation_error with the failing fields in data. For example: