An online store needs to know when a payment is completed. A CRM needs to know when a new request arrives from the website. There are two basic ways for one system to learn about events in another: ask regularly, or be told.
Polling: asking regularly
With polling, your system asks the other one every few minutes: "Is there anything new?". It is simple to build and works with almost any service that has an API. The downsides are delay - you learn about an event only at the next check - and waste: most requests return nothing, yet they still consume limits and resources.
Webhooks: being told
With a webhook, the other system sends a message to your address as soon as something happens. Information arrives almost instantly and there are no empty requests. The price is responsibility: your endpoint must be available, must verify that the message really came from the partner, and must handle it correctly even if the same message arrives twice.
How to make webhooks reliable
Check the signature or secret that the provider attaches to each message, so that nobody can send you fake events. Respond quickly and do the heavy processing in the background, otherwise the provider may decide the delivery failed and repeat it. Store an identifier of every processed event and ignore duplicates. Keep a log of incoming messages so problems can be investigated.
The practical combination
In practice the most robust integrations combine both approaches. Webhooks deliver events in real time, and a periodic check - for example once an hour or once a night - compares the state on both sides and catches anything that was missed while your server was being updated or the provider had an outage.
The short version
Polling is simple but slower and wasteful; webhooks are fast but require care. Use webhooks for speed, protect them with signatures and duplicate checks, and add a periodic reconciliation so that no event is lost.