Concepts

Errors

Failed requests return a non-2xx HTTP status and a JSON body of the form { "error": { "code", "message", "request_id" } }. Branch on code, show message to developers, and quote request_id to support.

TuskMail API: Errors

What does an error look like?

422 Unprocessable Entity
{
  "error": {
    "code": "validation_error",
    "message": "to: 'amina@' is not a valid email address",
    "request_id": "req_8f2c1a9d03b44e7a1c5d"
  }
}

Every response, successful or not, carries an X-Request-Id header with the same identifier.

Which error codes can I get?

HTTPcodeMeaning
400bad_requestThe request could not be processed as sent.
401invalid_credentialsMissing or wrong API key, mailbox email or app password, or the app password was revoked.
402payment_requiredThe domain is blocked because the subscription is overdue.
403forbiddenApp password not allowed from this IP, or the mailbox is disabled.
404not_foundMessage, folder or attachment not found.
413payload_too_largeAn uploaded attachment is over 25 MB.
422validation_errorA field is missing or invalid. The message names the field.
429rate_limitedToo many requests. See Retry-After.
429daily_limit_exceededThe key's daily sending limit was reached.
502upstream_errorThe mail server could not complete the request. Safe to retry with backoff.

How should I handle errors?

  • 4xx (except 429): fix the request. Retrying will not help.
  • 429: wait for Retry-After, then retry.
  • 5xx: retry with exponential backoff, using an idempotency key for sends.