Error contract
Device and app API errors include a top-level machine-readablecode. Existing
detail, message, error, and validation errors fields remain available;
their shape depends on the endpoint. Branch on code, not message text.
/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 inX-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.