error. Las respuestas exitosas nunca la incluyen.
message y mantienen error fijo en "Unauthorized":
code estable con el que puedes comparar y,
a veces, un objeto context con identificadores relacionados:
error como texto para personas y
code como el valor con el que debes decidir la lógica.
Códigos de estado
Validación de parámetros
Cada endpoint valida sus parámetros antes de hacer cualquier trabajo. Una validación fallida regresa422 con un mensaje
que nombra el parámetro, por ejemplo:
Los tipos incorrectos y los valores fuera de una lista permitida fallan de la misma forma, con un mensaje que nombra el parámetro.
Compara con el código de estado y el nombre del parámetro, no con la frase exacta.
Errores de negocio
Las reglas de negocio regresan422 con una frase descriptiva, por ejemplo
"no shipping_label with id 99 was found.". Cada endpoint en la referencia de la API enlista los mensajes que puede
regresar. Algunos mensajes se regresan en el idioma del país del almacén (español o portugués) cuando
provienen del lado de operaciones; la referencia los muestra textualmente.
Excepciones a tener en cuenta
Algunos endpoints todavía no siguen los patrones anteriores. Manéjalos de forma explícita:- Errores con estado
200.POST /orders/cancel,POST /orders/delete,PATCH /orders/{id}/holdyPATCH /orders/{id}/unholdpueden responder200con una llaveerror, por ejemplo, cuando la orden está en un estado que no permite la acción. Revisa si el cuerpo traeerrorincluso con200. - Click and collect. Estos endpoints responden
404con uncodecomoORDER_NOT_FOUND, y el cuerpo de su500es{"error": "unexpected_error", "timestamp": 1760000000}. - Creación de órdenes.
POST /orders,POST /orders/create-and-shipyPOST /brazil/ordersresponden500con{"error": "unexpected error"}y sin timestamp. - Identificadores desconocidos. Algunos endpoints responden
500en lugar de422para unstore_ido unshipping_method_idque no existe. Revisa los identificadores antes de reintentar un500.