Skip to main content

Continuous polling vs. webhook subscriptions

There are two ways to find out that something changed in Kavitro: ask repeatedly, or be told. This page covers when each is appropriate, and why the answer is usually "both".

What polling costs you​

Polling means calling the API on a schedule to look for changes, whether or not anything happened. Two things make that expensive.

It spends your request budget. Authenticated requests are capped at 500 per minute per token. A job that polls ten list endpoints every thirty seconds spends 20 requests a minute doing nothing but asking. Tighten the interval or add resources and that grows quickly, and it competes with the requests your application actually needs to serve users.

Most of the calls find nothing. The tighter your interval, the higher the proportion of empty responses, and the interval is what determines how stale your data can be. You pay more to be less wrong, and you never get to zero.

Webhooks invert both. Kavitro pushes an event when something changes, so there is nothing to spend when nothing happens, and deliveries do not count against your request rate limit at all. Notifications normally arrive well under a minute after the event.

Where polling still wins​

Polling is the better tool when:

  • You cannot accept an inbound connection. Webhooks need a publicly reachable HTTPS endpoint. If you are behind a firewall with no way to expose one, polling is the option you have.
  • You only need periodic snapshots. A nightly export or a warehouse sync does not benefit from per-change notifications. One scheduled query is simpler than an endpoint, a queue and a signature check.
  • You need changes that raise no event. Not everything emits one. Editing a rich-text description produces no updated event, for instance - see event types.

Where webhooks win​

Webhooks are the better tool when you need to react promptly to changes that arrive unpredictably: notifying a user, kicking off a workflow, keeping another system in step. That is most integrations.

Use both​

The two are not really alternatives, and treating them as an either/or is how integrations end up quietly missing data.

Webhook delivery is not guaranteed. An endpoint that stays down long enough will have events dropped once the retry schedule is exhausted, ordering is not guaranteed, and some changes never raise an event.

So the shape that actually works is:

  1. Webhooks for latency. React to changes as they happen.
  2. A periodic reconciliation query for correctness. Sweep for anything changed since your last sync and fill in whatever the webhooks missed.

The reconciliation job can run infrequently - hourly, or nightly - because it is a safety net rather than your primary path. That combination costs a fraction of what tight polling does, and it is more reliable than either approach alone. See best practices.