Begin hier

Fouten en retries

Parse de standaard JSON-foutenvelop en bepaal wanneer een retry veilig is.

Foutenvelop

Mislukte JSON API-calls gebruiken één error-object op het hoogste niveau met een leesbare message, de numerieke HTTP-status en een optionele, stabiele code. Het OpenAPI-contract verwijst naar dit schema voor verwachte en onverwachte fouten.

Foutrespons
{
  "error": {
    "code": "invalid_request",
    "message": "A verified From domain is required",
    "status": 403
  }
}

Clientfouten

Corrigeer invoerfouten met 400 voordat je het opnieuw probeert. Vervang of trek ongeldige credentials in na een 401. Een 402 vereist een betaald abonnement, 403 markeert een beleids- of rechtengrens, 404 is een ontbrekende resource binnen de tenant, 409 is een status- of idempotentieconflict, 413 overschrijdt de limieten voor bijlagen en 422 dekt validatie of suppressie.

Beslissen over retries

Probeer fouten door authenticatie, validatie, suppressie of conflicten niet automatisch opnieuw. Een 423 betekent dat precies die From-identiteit is gepauzeerd; stop die stroom, corrigeer de ontvangers en probeer het pas opnieuw als de rollende metrics weer in orde zijn. Een caller mag een tijdelijke 429-, 502- of 503-respons opnieuw proberen met begrensde exponential backoff en jitter. Gebruik dezelfde Idempotency-Key en een identieke JSON-payload wanneer je één logische verzending opnieuw probeert.

Context voor support

Noteer het tijdstip van het request, de route, de HTTP-status, het SendHQ-resource-ID en niet-geheime foutvelden. Zet nooit een API-sleutel, sessiecookie, berichttekst of ontvangerslijst in een supportmelding.