Tu conector mantiene a CrossUp al día mandando cada cambio cuando pasa. Si tu sistema borra sin avisar, un snapshot una vez por día barre lo que ya no está.

Las dos rutinas de tu conector

1 · Cada cambio, cuando pasa

Cambió un precio, entró stock, se borró un producto, se pagó una orden: tu conector manda sólo eso.

2 · Todo, una vez por día (opcional)

Sólo si tu sistema no puede avisar lo que borra: manda el catálogo completo y lo que no vino se da de baja.
Si tu conector también manda los delete, la rutina 1 alcanza.

Rutina 1: mandar lo que cambió

CrossUp te da un endpoint y tu conector le hace un POST cada vez que algo cambia. Cómo se entera tu conector del cambio depende de tu sistema: CrossUp no necesita saberlo.
1

Algo cambia en tu sistema

Un precio, un stock, un producto nuevo o borrado, una orden nueva o que cambió de estado.
2

Pasalo al formato de CrossUp

Cada entidad lleva su external_id (el id en tu sistema) y una operación: upsert si se creó o cambió, delete si se borró. Los campos de cada una están en El modelo canónico.
3

Mandalo

Un POST a /observations, con hasta 500 entidades. Cada una vuelve con su resultado, igual que en la sincronización inicial.
Un delete no lleva document. Las órdenes nuevas, o las que cambian de estado, van por acá como order.

Rutina 2 (opcional): el snapshot diario

Usala sólo si tu sistema no puede mandar los delete. Es la misma secuencia que la sincronización inicial: abrís un run por entidad, mandás todo en páginas y lo cerrás. Al cerrar, lo de ese tipo que no vino se da de baja. Programalo una vez por día, en el horario de menos movimiento de tu tienda.
Mientras el run está abierto, no mandes observaciones de esa entidad. Un producto que entre por la rutina 1 durante el run se daría de baja al cerrar, y una página vieja podría pisar un cambio más nuevo.
El snapshot diario es para el catálogo, no para las órdenes. Un snapshot es «todo»: si cerrás un run de order con las órdenes de hoy, las anteriores se dan de baja. Después de la sincronización inicial, las órdenes van siempre por la rutina 1.

Si algo falla, reintentá

Reenviar lo mismo nunca duplica nada, así que ante un corte o un timeout podés mandar el lote entero otra vez.
  • Con revision: un entero que sólo crece, como un updated_at en milisegundos. Se aplica sólo si es mayor que la última; si no, vuelve stale y no pisa nada.
  • Sin revision: CrossUp compara el contenido. Si es idéntico al último, vuelve unchanged.
Si tu sistema no tiene nada que sólo crezca, omití revision.

Lo que no valida: cuarentena

Una entidad que no cumple el contrato vuelve quarantined. Su reason nombra el campo: document.quantity: required. Las demás del lote entran. Corregí esa entidad y reenviala sola. Lo que vuelve accepted ya es de CrossUp. Queda archivado y llega al catálogo aunque algo del otro lado esté caído. Tu conector no tiene que reintentarlo.

Glosario

  • Conexión: tu tienda en CrossUp. Su id es el connection_id (cn_…).
  • Observación: una entidad que cambió, con upsert o delete.
  • Snapshot: «acá está todo» de un tipo de entidad. Al cerrarlo, lo que no vino se da de baja.
  • Run: un snapshot abierto (snp_…). Sin cerrar, expira a las 24 horas.
  • Revisión: un entero que sólo crece y dice cuál versión es la más nueva.
  • Cuarentena: lo que no validó; reason dice por qué.

Qué vas a ver

Cada cambio que mandás vuelve accepted. Un reintento vuelve unchanged o stale, y tu catálogo queda con la versión más nueva.

Si no lo ves

El modelo canónico

Qué campos lleva cada entidad y cuáles se omiten.

SDK de conector y protocolo

El contrato, y cómo hablarlo en tu lenguaje.