Saltar al contenido principal
Toda respuesta de error es un objeto JSON con una llave error. Las respuestas exitosas nunca la incluyen.
Los errores de autenticación agregan una llave message y mantienen error fijo en "Unauthorized":
Algunos errores de negocio en órdenes, devoluciones y reabastecimientos (replenishments) agregan un code estable con el que puedes comparar y, a veces, un objeto context con identificadores relacionados:
Cuando un endpoint regresa códigos, su página de referencia los enlista. Trata 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 regresa 422 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 regresan 422 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}/hold y PATCH /orders/{id}/unhold pueden responder 200 con una llave error, por ejemplo, cuando la orden está en un estado que no permite la acción. Revisa si el cuerpo trae error incluso con 200.
  • Click and collect. Estos endpoints responden 404 con un code como ORDER_NOT_FOUND, y el cuerpo de su 500 es {"error": "unexpected_error", "timestamp": 1760000000}.
  • Creación de órdenes. POST /orders, POST /orders/create-and-ship y POST /brazil/orders responden 500 con {"error": "unexpected error"} y sin timestamp.
  • Identificadores desconocidos. Algunos endpoints responden 500 en lugar de 422 para un store_id o un shipping_method_id que no existe. Revisa los identificadores antes de reintentar un 500.

Errores inesperados

El timestamp identifica el fallo en los logs de Cubbo. Inclúyelo cuando escribas a integraciones@cubbo.com.