Skip to main content

Error contract

Device and app API errors include a top-level machine-readable code. Existing detail, message, error, and validation errors fields remain available; their shape depends on the endpoint. Branch on code, not message text.
This contract covers /api/v1/execution/start_device, device-proxy routes, device-session routes, streaming worker-connection routes, and /api/v1/apps routes, including app creation, build upload/finalization, and remote-build runner availability. The legacy /api/v1/builds routes use the same contract. The partner connections API retains its separate nested error.code envelope. Do not treat a product error as a partner connection error.

Request correlation

Send a UUID in X-Request-ID to correlate your request with Revyl diagnostics. Revyl echoes its canonical UUID spelling on success and error responses. If the header is missing or invalid, Revyl generates a UUID. Record the returned header when reporting a failure. A request ID is not an idempotency key and does not make a repeated mutation safe.

Codes and recovery

Existing feature-specific codes are preserved. Handle unknown codes as errors using the HTTP status and retain their request IDs; clients should not require a closed list of codes. Retry-After, when supplied, is a delay in seconds. It is not a promise that capacity will be available afterwards. No retry delay is invented when Revyl does not know one. An ordinary full device pool can return 200 with an initializing or queued session. Likewise, runner availability can return 200 with available: false. These are status results, not error responses; no slots_full error is implied.

Recover an existing app

For an app-name conflict, the response retains its existing human-readable detail and adds the organization-scoped ID:
The ID comes only from the caller’s organization and excludes deleted apps.