Venga de VTEX, de un headless o de un ERP, tu catálogo llega a CrossUp como cinco entidades. Todo es opcional salvo lo que identifica, y un campo que tu sistema no tiene se omite: no va vacío ni en cero.

Las cinco entidades

Todas se identifican por su external_id, el id que tienen en tu sistema. item, variant y availability terminan en el mismo producto, y se pueden mandar por separado. La disponibilidad lleva el external_id de su variante, sin sufijos. Una variante tiene una sola disponibilidad: si mandás dos depósitos para la misma, el segundo pisa al primero.

Los campos

Tres tipos que no son lo que parecen

  • Dinero es un string. amount es un decimal como texto: un float binario cambia el precio y aparece como un centavo de menos en el checkout.
  • Texto es por idioma. Un idioma que no tenés se omite: no copies el español en el portugués.
  • Stock tiene tres estados. unlimited, tracked y unknown, y unknown no es cero.

Las órdenes

No hay una entidad de clientes: lo del comprador viaja dentro de la orden, y todo es opcional. Lo que mandes ahí no lo escribas en ningún log. Para que la venta quede medida, la orden tiene que poder cruzarse con la recomendación:
  • El external_id de la orden es el mismo cart_id que tu tienda manda al pedir recomendaciones.
  • Cada línea trae variant_external_id. Una línea cuenta como vendida si su variante está en la orden.
Cuando la orden cambie (el pago, el total), mandala de nuevo: el cruce se rehace y da lo mismo, sin duplicar.

Cómo llega a tu tienda

CrossUp conserva tus external_id y asigna sus propios ids (itm_…, var_…). Tu tienda puede pedir un producto por tu id con GET /v1/catalog/items/by-external/{external_id}.

Qué vas a ver

Cada entidad aceptada aparece en el catálogo con los campos que mandaste, y ninguno más. Un quarantined dice el campo exacto que no validó.

Si no lo ves

SDK de conector y protocolo

El contrato de estas entidades, en OpenAPI.

Qué decide CrossUp

Qué entra, qué sale y qué queda de tu lado.