Events
Cursor-paginated event log for reconciliation and missed webhooks
Every domain event ListBee emits is persisted and queryable via GET /v1/events. Use it to reconcile orders when your webhook endpoint was down, to bootstrap a worker against historical activity, or as a polling-primary delivery channel when you don’t want to expose a public callback.
Events outlive webhook delivery — even if agent_callback_url failed all 7 retries, the event is still here.
Event types
Listing lifecycle (create/publish/archive) is not emitted — the agent is the mutator, so it’s self-knowledge.
Listing events
Cursor-paginated. Filter by type, listing_id, order_id, and after (event ID).
Event shape
data is the same structured payload delivered to agent_callback_url — no follow-up API call needed to enrich it.
Reconciling missed webhooks
Keep a cursor (last processed event ID) in durable storage. After a restart or outage, poll from the cursor forward:
This pattern works as a standalone channel (no webhook URL needed) or as a backstop behind a webhook consumer.
When to use events vs webhooks
Webhook delivery has retries and a circuit breaker — events are always durable regardless. See Fulfillment for delivery mechanics.
Key fields
Related
- Fulfillment — webhook delivery, retries, redelivery
- Orders —
POST /v1/orders/{id}/redeliverfor one-order replay