Sincronización

Pangui publica una vez al día, después del pipeline de las 05:00 (Santiago). Cada respuesta trae meta.data_as_of: el instante hasta el que llegan los datos.

Opción 1: el snapshot diario

GET /beta/snapshot entrega un archivo NDJSON comprimido (gzip): una oferta por línea, con el mismo esquema de la API. Cada snapshot es inmutable. Los headers X-Pangui-Sha256 y X-Pangui-Row-Count te dejan verificar que lo descargaste completo; si lo procesas dos veces, llegas al mismo estado.

Opción 2: upsert por id usando updated_at

Cada oferta tiene un id estable y un updated_at que cambia sólo cuando cambia algo que publicamos: el contenido de la oferta o su estado. Una oferta que no cambió conserva su updated_at indefinidamente.

• Haz upsert por id y quédate con la versión de updated_at más reciente.
• Las bajas no desaparecen en silencio: una oferta que vence o que la fuente retira sigue publicada durante 90 días con status: expired o withdrawn, y su updated_at marca ese cambio. Consulta con status=expired o status=withdrawn para recibirlas.
• Si te desconectas más de 90 días, vuelve a bajar un snapshot completo: las bajas más antiguas ya no están en el catálogo publicado.

valid_until es una fecha calendario, así que también puedes calcular la expiración por tu cuenta: las dos vías coinciden.

Próximamente

Un parámetro updated_since para pedir sólo lo que cambió desde tu última sincronización. La semántica de updated_at ya está diseñada para eso: toda oferta que cambia aparece con un updated_at posterior al data_as_of del publish anterior. Mientras tanto, la API rechaza parámetros desconocidos con 400, para que nadie reciba la lista completa creyendo que es un delta.