Errors and retries

Transport failures and run failures are separate. An HTTP error means the API request failed. A successful 202 or 200 can still describe a run that later reaches failed.

HTTP status codes

Status	Meaning	Client action
`400`	Malformed request	Fix the request
`401`	Missing, invalid, expired, or revoked credential	Replace the credential
`402`	Workspace has insufficient cloud credits	Add credits or stop dispatch
`403`	Credential lacks the required scope	Replace it with a correctly scoped key
`404`	Resource is absent or not visible to this workspace	Verify the ID and workspace
`409`	State, concurrency, or idempotency conflict	Follow the response; do not blindly retry
`422`	Input or published Blueprint contract is invalid	Fix the payload
`429`	Rate or concurrency limit	Honor `Retry-After` and back off
`5xx`	Transient platform failure	Retry safe requests with bounded backoff

Error bodies have a detail field. When present, the X-Request-ID response header correlates the request with platform logs.

Retry policy

The SDKs retry transient connection failures, 408, 429, and 5xx responses for safe GET requests. The default is two retries with bounded exponential backoff. Mutation requests are not retried unless run creation includes an idempotency key. Cancellation is idempotent but the SDK sends it once.

Do not retry a create request automatically unless it carries the same stable idempotency key and the same body.

SDK errors

Both SDKs expose these subclasses of InfragridError:

AuthenticationError
PermissionDeniedError
NotFoundError
RateLimitError
ServerError
APIConnectionError
APITimeoutError

Errors preserve status, a bounded response body, and requestId / request_id when available.

Terminal run failures

A failed run includes a display-safe error_code and error_message. Do not infer success from an HTTP 200 alone—always inspect the run status. When opening a support case, include:

run ID
request ID, when available
SDK name and version
terminal status
error_code

Never include the API key, website credentials, cookies, or extracted personal data.

Timeouts and cancellation

SDK wait helpers enforce an overall client-side deadline. A wait timeout does not automatically prove the cloud run stopped. Retrieve the run again or call the cancel endpoint if the business operation should end.

Get started

Build automations

Production

HTTP status codes

Retry policy

SDK errors

Terminal run failures

Timeouts and cancellation

​HTTP status codes

​Retry policy

​SDK errors

​Terminal run failures

​Timeouts and cancellation

HTTP status codes

Retry policy

SDK errors

Terminal run failures

Timeouts and cancellation