Tu conector mantiene a CrossUp al día con dos rutinas: manda cada cambio cuando pasa, y cada tanto manda todo para barrer lo que se borró. Las dos usan la misma clave y el mismo connection_id.

Las dos rutinas de tu conector

1 · Cada cambio, cuando pasa

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

2 · Todo, cada tanto

Una vez por día, por ejemplo, manda el catálogo completo. Lo que no vino se da de baja.
La primera mantiene a CrossUp al día. La segunda es la red: encuentra lo que se borró sin que tu sistema avisara.

Rutina 1: mandar lo que cambió

1

Enterate del cambio

Tu conector escucha el webhook de tu sistema, o le pregunta cada pocos minutos qué cambió. Si tu sistema no permite ninguna de las dos, la rutina 2 alcanza.
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 /internal/v1/connections/{connection_id}/observations, con hasta 500 entidades. Cada una vuelve con su resultado, igual que en la sincronización inicial.
Así viaja un cambio de precio y un producto borrado en el mismo pedido:
Un delete no lleva document. Las órdenes nuevas, o las que cambian de estado, van por acá como order.

Rutina 2: el snapshot periódico

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. Vos elegís la frecuencia: una vez por día o por semana.
El snapshot periódico 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.