Skip to main content

Introduction

The CUDO Compute API uses the Google AIP-193 Error Model for all error responses. This provides a consistent, machine-readable structure while keeping messages helpful for humans. Every non-2xx response body will be a single JSON object shaped like:

Fields

The status string is the canonical error code name (e.g. INVALID_ARGUMENT). The numeric HTTP status is returned separately as the HTTP response status line and repeated in code for client convenience.

Detail objects

Each element in details is a typed envelope with an @type URL identifying the Protobuf / schema. We leverage standard Google types. Examples: If you need richer structured data for automation, always prefer reading details over parsing message.

Canonical codes used

Below is the subset of AIP-193 / gRPC canonical codes you may encounter and how we map them to HTTP statuses:
If you receive a code not listed here, treat it like UNKNOWN and contact support.

Examples

Below are representative responses for common categories. Only standard google.rpc detail types are used (no custom types) to keep automation straightforward.

Invalid Arguments (400)

Client handling guidance

Retry Strategy

We recommend capped exponential backoff (e.g. base=500ms, multiplier=1.6, max=30s, jitter 0-100%). If a RetryInfo.retryDelay is present, start with that delay before resuming your normal backoff sequence.

Do not parse human readable messages

Never parse message strings-use status, structured details, and (when present) ErrorInfo.metadata for automation.

Versioning & stability

The error envelope fields listed above are stable. New canonical codes (rare) or new details types may appear without prior notice but will always be additive. Breaking changes (removal or semantic change of existing fields) are not planned. If absolutely required, they will be announced in the Changelog with at least 90 days’ notice.

Testing errors

During development you can deliberately trigger certain errors:

Support

Include the following when contacting support about an error:
  1. status & HTTP code
  2. Endpoint + HTTP method
  3. Timestamp
  4. (If relevant) The @type detail objects
This enables rapid trace correlation in our internal logs.
If you have suggestions for additional structured error detail types, please open an issue or contact support with your use case.