Polling is easier to build and harder to live with. Here’s how to decide which approach fits your volume and latency requirements.
Every messaging integration eventually needs to answer the same question: how do you find out what happened to the message you sent?
Polling is the obvious first answer. You store the batch ID, and a scheduled job asks the API for status every few minutes. It’s simple, it needs no public endpoint, and it works behind a firewall. It also scales badly — at ten thousand messages a day you’re making a great many requests to learn that nothing has changed.
Webhooks invert the relationship. You expose an endpoint, register it once, and Esendex posts to it when state changes. Latency drops from minutes to seconds and request volume collapses.
The trade-off is operational. You now own a public endpoint that must be available, must respond quickly, and must tolerate duplicate deliveries. Most teams should start with polling in development and move to webhooks before launch.
