turgo surfaces errors two ways: API errors with stable machine codes and in-app status messages on mailboxes, integrations, and workflows. Handle API errors by code, and read in-app statuses for the plain-language cause.
API error codes
The envelope carries a stable code, a message, and a request_id (see API error codes reference). Common ones: 401 invalid_key (see Why is the API returning 401?), 403 insufficient_scope, 404 not_found, 409 conflict (refetch and retry), 422 validation_failed (see the details array), 429 rate_limited (honor Retry-After). 500/503 are retryable with backoff.
Handle by code, not message
Message wording improves over time; codes are stable. Branch your integration logic on the code. Always log the request_id — support can trace any single call from it.
In-app statuses
Mailbox Warming/Unhealthy (see Why is my mailbox marked unhealthy?), integration Disconnected (see Why did the integration disconnect?), workflow Paused (see Why is my workflow paused?), and draft Held (see Why is the agent draft held for review?) each carry a specific reason on their card. These are plain-language, not codes — read the reason and follow its fix.
When to check status.turgo.ai
Sustained 5xx errors or platform-wide symptoms warrant a look at status.turgo.ai before you debug your own side. If it's green and the problem persists, file a ticket with the request_id.
