La API de devoluciones modela el ciclo completo de una RMA: se crea una devolución sobre un pedido, se aprueba o rechaza, el cliente envía la mercancía de regreso, el comerciante la recibe y finalmente se procesa el reembolso (o intercambio). Cada paso es un endpoint separado, con su propio permiso.
Progresión real de estados
El catálogo real de estados de una devolución tiene 12 valores: return-requested, return-approved, return-rejected, return-shipped, return-received, inspecting, refund-pending, refunded, exchange-pending, exchange-shipped, exchange-completed, closed. Nota que además del flujo de reembolso existe un flujo de intercambio (exchange-*) — el tipo de devolución (type) puede ser refund, exchange o store-credit.
Envelope de respuesta
Toda respuesta exitosa de recurso único sigue { "data": {...} }; las listas usan { "data": [...], "meta": { "pagination": {...} } }. Los errores siempre son { "error": { "code", "message", "details?" } }.
Devuelve el conteo de devoluciones agrupado por estado.
200
{ "data": { "...": "..." } }
Permiso requerido:returns:read
Grupos de conteo no confirmados
El endpoint existe y devuelve un conteo por grupo de estado de devolución, pero los nombres exactos de esos grupos no fueron confirmados en esta auditoría (no asumimos que coincidan con los grupos de estado de pedidos — pending, preparing, completed, cancelled, problematic, all — porque son catálogos distintos). Verifica el shape exacto contra una respuesta real antes de parsearlo por nombre de campo.
defective, wrong-item, size-fit, quality-issue, not-as-described, changed-mind, arrived-late, damaged-shipping, duplicate-order, other
Formato con guion, no guion bajo
Todos los valores de reason usan guion (wrong-item, no wrong_item). Enviar un valor con guion bajo falla la validación.
items se identifica por sku, no por itemIndex
A diferencia de POST /orders/{orderId}/prepare (que identifica ítems por itemIndex), la creación de una devolución identifica cada ítem por sku: el servicio busca ese SKU dentro de order.items y falla con OrderValidationError si no lo encuentra, o si quantity excede la cantidad original del pedido.
type no se exige en runtime pese a que el tipo TypeScript lo marca requerido
El validador de transporte (createReturnSchema) solo exige items y reason — no valida type en absoluto. Y a nivel de librería, createReturn() asigna newReturn.type = input.type directamente, sin ningún chequeo: si omites type, el campo queda undefined en el documento guardado, sin error. La interfaz TypeScript CreateReturnInput marca type como no-opcional, pero eso NO se traduce en una validación real en ninguna capa — es una promesa de tipo que el código no cumple. Si tu integración depende de que toda devolución tenga type, envíalo explícitamente; no asumas un default.
Actualiza campos de una devolución existente. Se requiere al menos un campo en el body.
orderIdstringrequired
ID del pedido
returnIdstringrequired
ID de la devolución
statusstring
Nuevo estado de la devolución.
overallConditionstring
Condición general de la mercancía (ver catálogo en la sección de recepción).
inspectionNotesstring
Notas de la inspección de la mercancía.
rejectionReasonstring
Motivo de rechazo, si aplica.
skipMerchandiseReturnboolean
Si se omite el retorno físico de la mercancía (ej. reembolso sin devolución).
inventoryDispositionobject
Qué hacer con el inventario devuelto: { locationId, locationName?, placeType: 'available'|'reconditioning'|'damaged'|'shrinkage', placeCode?, costImpact?, currency? }.
refundobject
Datos de reembolso asociados: { amount, currency, method, status, transactionId? }.
shipmentInfoobject
Información del envío de retorno: { trackingNumber?, carrier?, customCarrierName?, trackingUrl?, waybillId?, labelUrl?, shippedAt?, receivedAt?, cost? }.
{ "inspectionNotes": "Producto sin daños visibles", "overallCondition": "like-new"}
Ningún valor de condition coincide con new/used/damaged/unusable — esos no existen en el catálogo real. Usa exactamente uno de los 7 valores con guion listados arriba.
El catálogo real tiene exactamente estos 3 valores, con guion. No existe un cuarto valor genérico ("etc."); enviar original_payment (guion bajo) falla la validación.