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.

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

All of these are 429. Responses to profile calls carry your current window in headers - see Limits.

Errors from the browser

These come from the pod running your browser rather than the API gateway, so you will usually see them on start, on /scrape, or on a cookie call.

Validation errors

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