Webhook e sincronizzazione

Ricevi gli aggiornamenti delle prenotazioni, riallinea con il feed incrementale, controlla job e audit.

Webhook

curl -X POST "$TAKO_API_URL/api/v1/webhooks/subscriptions" \
  -H "Authorization: Bearer $TAKO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://gestionale.example/webhooks/tako",
  "supplierId": "supplier-id",
  "headers": {
    "Authorization": "Bearer receiver-secret"
  }
}'

Usa supplierId per limitare la sottoscrizione a un fornitore, oppure omettilo per tutto il tenant. Il payload è l’envelope BOOKING_UPDATE con id deterministico per deduplicare; risposte 2xx confermano la consegna. 429/5xx e errori di rete ritentano dalla coda; errori permanenti incrementano il contatore e disabilitano la sottoscrizione dopo 20 fallimenti.

Feed incrementale

curl "$TAKO_API_URL/api/v1/bookings?updatedSince=2030-06-01T00:00:00Z&limit=100" \
  -H "Authorization: Bearer $TAKO_API_KEY"

La risposta contiene items e nextCursor; continua inviando lo stesso updatedSince con il cursore fino a null. Il cursore è opaco e l’ordine è updatedAt/id. I webhook non sono mai l’unico meccanismo: riallinea periodicamente con il feed.

Job e audit

Le scritture che richiedono propagazione generano eventi elaborati dal worker. Una risposta HTTP riuscita conferma l’operazione locale, non la ricezione da parte del canale.

Endpoint	Uso e limite
GET /sync-jobs?status=FAILED	Ultimi 200 job, con attempts. Filtri status, provider e supplierId.
POST /sync-jobs/{id}/retry	Solo FAILED con evento di origine disponibile; consegna asincrona.
GET /audit-logs?entityType=Booking&entityId=…	Ultimi 200 eventi, dal più recente; non è un feed di sincronizzazione.
POST /webhook-events/{id}/retry	Rielabora eventi Viator in stato RECEIVED/FAILED.

Stati job: PENDING, RUNNING, RETRYING, SUCCEEDED, FAILED. Risolvi la causa prima del retry manuale; chiamarlo più volte crea più eventi.