[sly010]

Aside: Webhooks are always a pain.

Implementing polling is easier for both sides.

I routinely have to integrate with random 3rd party systems, some with no or broken webhooks, some with no API at all. It turns out for my customers (this may not be always the case) eventual consistency is more important than timelyness.

What I do now every time I need to sync data from a third party is I always implement some sort of pull first with idempotent logic on my side. It's easier, and it allows me to just re-run things if something fails (e.g. network error, unexpected data in production, etc).

Only when that works reliably and only if required by the customer I implement a webhook, but I usually throw away most of the message and just wake up my polling worker that is otherwise polling relatively slowly.

[beachy]

Long polling works brilliantly (where your API call blocks until there are some results or until timeout occurs - then you loop and call again).

Long polling gives you the best of both worlds - easy programming model with instant alerting rather than the delay of normal polling.

The only downside really is the need for a more or less permanently open connection per client. As long as the server does not use a naive "thread per connection" model this can scale up to many hundreds of thousands of clients or more.

[Animats]

The good thing about long polling is that if the connection breaks, the keep-alive will time out and you'll know you're not getting updates. Assuming there's some keep-alive feature.

[MrBuddyCasino]

Thats what I did, too. Poll, fetch and remember and retry errors, and if possible implement a sliding window as a poor man's cursor using dateFrom / dateTo if available.