Polling and FIFO Endpoints

Let customers poll for events, or receive them in FIFO order.

Not every consumer can run a public endpoint, and not every consumer can handle events out of order. Polling Endpoints and FIFO Endpoints give your customers new primitives for building on your API.
Try for freeRead the docs

Not every consumer can take a webhook.

Regular webhooks push each event to a URL as soon as it happens. That works for most consumers, but some sit behind a firewall, run locally, or need every event in the exact order it was sent. Those customers can pick a different endpoint type instead.

Polling Endpoints

Consumers read events as a stream with an API key, picking up where they left off. It works behind firewalls and for local or short-lived consumers.

FIFO Endpoints

Events are delivered in strict order, for ledgers, state machines, and anything else that breaks when events arrive out of sequence.

We handle the load

Customers who would otherwise poll your API read from Svix instead, so that load stays off your servers.

Endpoint types

Polling for consumers that can't accept inbound requests. FIFO for consumers that need events in the order they were sent.

What a poll returns

Your customer calls a URL with an API key and gets back the events sent since their last poll.

Your API sends
{
  "eventType": "invoice.paid",
  "payload": {
    "id": "inv_123",
    "amount": 1000
  }
}
>_Terminal
$ curl …/polling-endpoint/poll_59q
{
  "data": [{
    "eventType": "invoice.paid",
    "payload": { "id": "inv_123", "amount": 1000 }
  }]
}
$ curl …/polling-endpoint/poll_59q
{
  "data": [{
    "eventType": "invoice.paid",
    "payload": { "id": "inv_124", "amount": 2500 }
  }]
}

More Use Cases

See all Advanced Destinations
Data WarehousingStream events to S3, Snowflake, Redshift, and other storage.OpenTelemetrySend events as traces to Datadog, Grafana, or any OTel backend.Message QueuesDeliver events to SQS, EventBridge, and RabbitMQ.

When is polling better than webhooks?

When the consumer can't accept inbound requests, like a service behind a firewall, a script on a laptop, or a short-lived job. Polling also suits customers who process events in bulk, like storing a day of events for compliance.

How does a Polling Endpoint track what was read?

Each consumer polls with its own consumer ID and commits the offset of the last message it processed. The next poll continues from there, and uncommitted messages come back again once their lease expires.

Can a Polling Endpoint return only some event types?

Yes. Like webhook endpoints, Polling Endpoints filter by event type and channel, so each customer only reads the events they subscribed to.

Why not make every webhook FIFO?

Strict ordering means each delivery waits for the previous one to succeed, which limits throughput. FIFO Endpoints send events in batches to make up for it, with batch settings your customers control in the App Portal.

Do I need to change how I send events?

No. You keep calling the same message API, and regular webhook endpoints, Polling Endpoints, and FIFO Endpoints can all receive the same events side by side.

Start sending webhooks today, no credit card required.

Get started for freeRead the docs