Skip to main content
Use the status code and machine-readable response fields to decide what to do next. Do not branch on a human-readable error sentence or assume that a timed out write failed.
Preview. The published OpenAPI operation remains the authority for its response codes and any endpoint-specific retry behavior.

​
Read the response body

Most Registry, Skill, Agent, File, and MCP failures use an application/problem+json body with title, status, detail, and stable code. Preserve trace_id when it is present. OTLP ingestion instead returns its documented JSON error shape with code, message, and details. Log the status, stable code, operation, and trace ID when available. Do not log the bearer credential, request body, or a bundle’s contents.

​
Recover by status

​
Retry writes deliberately

Safe retries depend on the operation. For example, OTLP ingestion accepts X-Atlan-Ingest-Id to identify the same batch on a retry. Skill uploads can return the existing head when the bundle is byte-identical, but callers should still read the resulting Skill and version before moving on. Do not add a generic retry loop around every POST, PATCH, or archive call. If a write times out or returns a 5xx response, read the intended resource first and retry only when the endpoint contract makes the next action safe.

​
Get help without exposing data

For a CLI trace issue, create a support bundle and inspect it before sharing:
For an HTTP request, share only the operation, status, stable error code, and trace ID where your support process permits it. Keep tokens, full request bodies, and customer content out of tickets and chat.