Skip to main content
The Compute API uses standard HTTP status codes and a consistent JSON error envelope.

Error response format

Errors use this structure:
Client logic should branch on error.code, never on error.message. Messages can change without changing the underlying error condition.

Common error codes

Handle 409 conflicts

409 Conflict uses error code CONFLICT, but it can have more than one cause.
  • Start: the instance is terminating or terminated, or the account does not have enough credit.
  • Stop: the instance is terminating or terminated.
  • Terminate: the instance is already terminated.
The error message does not distinguish these cases. Fetch the current instance state first. If a start request conflicts even though the instance can be started, check the account balance before retrying.
1

Fetch the current state

2

Check what blocked the action

Use the instance state to identify lifecycle conflicts. For start requests, also check whether the account has enough credit.
3

Retry only when the cause is resolved

Wait for a valid state transition or add credit as needed before sending the action again.

Handle rate limits

Rate limits apply per source IP address rather than per API key. Clients that share an egress IP also share the same request budget. A 429 Too Many Requests response includes a Retry-After header. Wait that many seconds before retrying.
Don’t pace requests against an assumed fixed limit. Treat the rate limit as subject to change and respond to 429 dynamically.

Handle server errors

A 500 response uses the generic message:
The message is intentionally generic. Use error.code for program logic and keep request_id for troubleshooting. For temporary server errors, retry after a short delay. If the problem continues, contact Support with the request_id.

Handle temporary capacity errors

A start request can return 503 Service Unavailable when no host currently has enough free capacity for the instance’s preset. The body uses INTERNAL_ERROR rather than a separate capacity error code. Retry with backoff, or choose a compatible preset in another region. This is a temporary capacity condition rather than a problem with the request itself.

Retry safely

Before retrying a destructive action such as terminate, fetch the instance state and confirm the action is still needed.

What to include when asking for help

Include:
  • The endpoint and HTTP method
  • The HTTP status
  • error.code
  • error.request_id
  • A redacted request if useful
Never include your API key.

Next step

Continue with API changelog to track API changes.