When one service needs information from another, there are two common approaches. Your application can call an API periodically to ask whether something changed, or the other service can send a webhook when a subscribed event occurs. The better fit depends on timing, event volume and how your system should behave when a request fails.

Use API polling when you need to ask

Polling means your application makes a request on a schedule or when a user asks for fresh data. It is simple to understand and works well when updates are infrequent, when the integration offers no webhook, or when your system needs a snapshot rather than an event notification.

The trade-off is that polling can create requests that return no new information, and the delay between checks determines how quickly your application notices a change. Poll too often and you may use unnecessary capacity or hit the provider’s rate limits; poll too slowly and the data becomes stale.

Use a webhook when a service can notify you

A webhook is an HTTP request sent to your endpoint when a particular event occurs. Instead of repeatedly checking, your application subscribes to the events it cares about and receives a notification as they happen. GitHub’s documentation describes webhooks as useful for near-real-time updates, such as starting a CI pipeline after a push. Its guide to webhooks and the REST API also notes that occasional lookups may be simpler with an API call.

Webhooks introduce their own work. Your endpoint must be reachable, identify the event and handle delivery failures. Providers have different retry policies, so check the provider’s documentation instead of assuming a failed notification will automatically arrive again.

Secure and process webhook requests carefully

Do not trust a webhook just because it reaches the right URL. For providers that support it, use a high-entropy secret and validate the request signature against the original payload before processing. GitHub documents HMAC-based validation with its X-Hub-Signature-256 header in its webhook validation guide. Store the secret outside source control and compare signatures with a constant-time comparison supported by your language.

Respond quickly, then move longer work to a queue. GitHub asks webhook endpoints to respond within 10 seconds and recommends asynchronous processing when work takes longer. Record the provider’s delivery ID and make your handler safe to run twice: duplicate or replayed deliveries should not create duplicate orders, deployments or notifications. Verify the event type and action before acting on its contents.

Many integrations use both

A webhook can tell your application that an object changed; an API call can then fetch the latest authoritative details. This pattern keeps notification traffic low while letting your application request the complete record when it needs one. It can also help when webhook payloads are intentionally limited.

For example, a deployment service might receive a webhook when a repository changes, check the event and branch, then call the repository API to retrieve commit details before deciding whether to start a build. The webhook is the signal; the API supplies additional data.

Choose with a few practical questions

  • Does the user need an immediate answer, or can the system wait for the next check?

  • Does the provider offer webhooks for the event you care about?

  • Can you keep an endpoint available and secure it with signature verification?

  • What happens if a notification is delayed, duplicated or missed?

  • Would an API request after the event give you the authoritative data you need?

Recover from missed or repeated events

Design for the possibility that your endpoint is temporarily unavailable. Keep delivery logs with the event identifier, receipt time, processing result and any retry attempt. Use a bounded retry strategy with delay rather than repeatedly hammering a failing service, and provide an operational way to inspect or reprocess a failed event. The exact mechanism depends on the provider; some require manual redelivery or a separate reconciliation job.

For critical workflows, a periodic API check can act as a safety net. For example, compare the provider’s recent records with the events your application has processed and investigate gaps. Keep that reconciliation narrow enough to avoid recreating every item, and use idempotency keys or unique event records so replaying a notification does not duplicate its effect.

GitHub documents its own delivery behavior and manual redelivery options in its failed webhook deliveries guide. Other providers differ, so build to the contract you actually have.

Use polling for straightforward, occasional checks and webhooks for event-driven updates when the provider supports them. For production integrations, design for verification, queues, retries and duplicate deliveries from the start; those details are part of the integration, not optional polish.