Fenicia modela el ciclo de vida de un pedido como una máquina de estados finita: desde un estado dado, solo un conjunto específico de estados destino son válidos. Este artículo documenta la máquina completa (23 estados) y todos los endpoints que la operan.
¿Qué endpoint debo usar?
Usa accept, reject y cancel para las acciones comunes del comerciante — están optimizadas para su caso de uso y validan reglas de negocio específicas (por ejemplo, el catálogo de razones de cancelación). Usa el endpoint genérico transition cuando necesites mover el pedido a cualquier estado válido de la máquina que no tenga una acción dedicada.
23 estados. Cada fila indica los estados a los que puedes transicionar desde el estado actual; cualquier otro destino es rechazado con orders:invalid_transition.
Cuando consultas un pedido, su objeto _links incluye únicamente las acciones válidas para su estado actual. Las acciones posibles son: accept, reject, cancel, prepare, fulfill, returns. Si una acción no aparece en _links, no es válida en el estado actual del pedido.
El handler no lee ningún campo del cuerpo de la petición — envía {} o simplemente omite el body. Si el pedido pertenece a un canal que exige confirmar la aceptación en el marketplace antes de aceptar localmente (hoy: Walmart), la aceptación se propaga automáticamente; no necesitas enviar nada para eso.
Permiso requerido:orders:update
curl -X POST https://api.fenicia.io/orders/65f3a1b2c4d5e6f7a8b9c0d1/accept \ -H "Authorization: Bearer fkapi_tu_api_key"
Mismo catálogo de reason que cancel, validación estricta
reject usa el mismo catálogo de 12 razones canónicas que cancel (ver la tabla en la sección "Cancelar un pedido" abajo) y la misma regla: note es obligatorio cuando reason es other. A diferencia de cancel (que acepta campos extra sin rechazarlos), el validador de reject es estricto: enviar un campo que no sea reason, motive, note o requestedBy es rechazado.
Establece el estado del pedido sin pasar por una acción con nombre. Útil cuando integras un flujo que ya conoce el estado destino exacto.
Establece directamente el estado de un pedido. Requiere permiso orders:update.
orderIdstringrequired
ID del pedido.
statusstringrequired
Estado objetivo.
{ "status": "preparing"}
204Sin cuerpo
(sin contenido)
Permiso requerido:orders:update
204 No Content — sin cuerpo
A diferencia de accept/reject/cancel/transition, este endpoint responde 204 No Content: no valida la transición contra la máquina de estados (no confundir con transition, que sí valida) y no devuelve el pedido actualizado. Si necesitas el pedido resultante, haz un GET /orders/{orderId} después.
Transiciona un pedido al estado indicado, validando la máquina de estados. Requiere permiso orders:update.
orderIdstringrequired
ID del pedido.
toStatusstringrequired
Estado objetivo. Debe ser una transición válida desde el estado actual.
reasonstring
Motivo de la transición, para el log de actividad. Obligatorio solo cuando la transición específica lo exige (ej. algunas transiciones a cancelled/rejected).
detailsstring
Detalle adicional en texto libre para el log de actividad.
flowProfilestring
Perfil de flujo contra el que se valida la transición: basic, intermediate (default) o wms-full.
El schema de transporte de este endpoint solo exige toStatus. reason no es obligatorio salvo que la transición puntual lo requiera (por ejemplo, transicionar a cancelled o rejected desde ciertos estados) — en ese caso, omitirlo devuelve validation:invalid_input.
La respuesta NO trae _links, y el pedido va anidado en order
A diferencia de accept/reject/cancel (que devuelven { data: { ...order, _links } }), este endpoint devuelve { data: { order, previousStatus, newStatus, hooks } } — el pedido completo vive en la clave order, sin _links, junto con el estado anterior/nuevo y la lista de hooks disparados (ej. ajustes de inventario).
orderIds debe tener al menos un elemento — un arreglo vacío rechaza toda la llamada con validation:invalid_input, no hay resultado parcial en ese caso. Con al menos un elemento, cada pedido se procesa individualmente: uno puede fallar (transición inválida, no encontrado) sin abortar los demás — revisa results[] para el detalle por pedido.
Este endpoint te evita tener que reimplementar la tabla de la máquina de estados en tu cliente: te devuelve directamente el conjunto de estados válidos para el pedido consultado. Está documentado en detalle en Consultar un pedido, junto con el resto de los enlaces HATEOAS del recurso.