Polling & reconciliation

Webhooks are the primary notification channel. Polling is the recovery and audit path — not a substitute for push.

curl -s -X GET "https://api.avrix.io/api/seller/v1/events?cursor=0&limit=100" \
  -H "Authorization: Bearer $AVRIX_API_KEY"

Design for both: consume signed webhooks in real time, and run scheduled pulls so a missed delivery never strands a paid buyer.

1. Confirm the endpoint failure in GET /webhooks/{id}/deliveries (status, response code, timestamps).
2. Replay with POST /webhooks/{id}/deliveries/replay when the original is still in the replay window. Replays carry a fresh eventId — correlate via the replay envelope’s original event id.
3. For orders, call GET /api/seller/v1/orders?orderReference=store-order-10432 and compare aggregates to your OMS.
4. For catalog drift, call GET /api/seller/v1/catalog/changes?since=<ISO8601> and apply tombstones / updates.
5. Escalate with X-Request-Id, orderReference, and timestamps when aggregates disagree past your SLA.

Run this even when webhooks look healthy (“trust but verify”).

Suggested daily (or hourly for high volume) loop:

1. Page GET /api/seller/v1/orders?from=<window start>&to=<window end>&limit=100 with meta.nextCursor until it is null — this is Avrix's authoritative list of your fulfilled orders in the window (each row carries orderReference, derived status, skuId, quantity, fulfilledAt, and keyIds — key ids, never plaintext).
2. Diff both ways against your storefront charges for the same window:
   • Orphan PSP captures (charge with no Avrix row) — investigate or refund at your PSP.
   • Orphan Avrix rows (row with no storefront order) — investigate duplicate idempotency misuse.
3. For any row in an unexpected state, drill in with GET /api/seller/v1/orders?orderReference=… (aggregate includes refunds[]).
4. Optionally sweep GET /api/seller/v1/events?since= for delivery rows you never processed.

After a total store-DB loss, rebuild the complete order ledger from the API alone: page the listing from your integration launch date to now (from=<launch>&limit=100, follow meta.nextCursor). Every row maps back to your store order via orderReference; re-request key material only where the buyer never received it, via the key recovery runbook — the listing itself never returns plaintext.

If policy forbids inbound HTTP:

1. On purchase, POST /orders with Idempotency-Key + orderReference → persist response entitlements immediately.
2. Poll GET /orders?orderReference=… until terminal aggregates match.
3. On mismatch past SLA, escalate with X-Request-Id.
4. On finance cycle, reconcile transactions / finance exports independently of webhooks.

Catalog-class events may arrive on a minute-scale freshness budget. Order hot-path recovery should use order aggregates and delivery replay first, not full catalog polls.

• Event reference
• Webhooks
• Reconciliation
• Idempotency