Errors
Status codes, error bodies and which errors are worth retrying.
Status codes
Nucleo uses standard HTTP status codes. Anything in the 2xx range succeeded; 4xx means the request must change before it can succeed; 5xx means something went wrong on our side.
| Code | Meaning | Retry? |
|---|---|---|
200 201 202 | Done. 202 means accepted for processing (for example Collector events). | — |
400 | Malformed request (body that is not JSON or XML, wrong envelope). | No |
401 | Missing, wrong or expired credential. | After fixing the credential |
403 | Valid credential, but not allowed here: wrong origin, feature turned off, scope missing. | No |
404 | Unknown resource, or a feature that is off for this store. | No |
409 | Conflict with the current state (for example an order already acknowledged). | No |
413 | Body too large. | After splitting the request |
422 | Validation failed: the body says which fields. | After fixing the fields |
429 | Rate limit reached. | Yes, after Retry-After |
500 502 503 | Our problem. | Yes, with backoff |
Error body
JSON APIs answer errors with a message and, for validation errors, an errors object with one entry per field:
{
"message": "The country field is required. (and 1 more error)",
"errors": {
"country": ["The country field is required."],
"qty": ["The qty field must be at least 1."]
}
}Some APIs add a machine-readable code or error next to the message (for example origin_not_allowed on the delivery promise or too_many_attempts on the returns lookup). Branch on the code, never on the text of message: the text can be reworded.
The OAuth endpoints follow RFC 6749 and answer {"error": "invalid_grant", "error_description": "…"}. The FFW warehouse interface answers in XML; its reference shows the exact envelopes.
Safe retries
Retrying is safe where the API makes it safe, and each reference page says so:
- Collector — give every event a
uid: an event already received is counted induplicatesand never stored twice. - Tracking webhook — an event identical to one already stored is ignored.
- Warehouse interfaces — repeated acknowledgements, shipments with the same tracking, stock levels and return outcomes have no double effect.
- Reads (
GET) are always safe to retry.
For every other write, check the outcome (for example look the return up) before sending the same request again after a timeout.