An order is marked dispatched in one app. Your support team still sees it as packing in another. The problem is not simply whether the integration runs. It is whether the next person can trust the status they see—and whether anyone notices when that status stops updating.
A webhook lets a source notify your integration when an event happens. Scheduled polling asks the source for information at intervals. Neither mechanism alone promises complete data, an exact delivery time or recovery after an outage.
The short answer: consider webhooks when the source offers suitable events and updates need to start promptly. Consider polling when scheduled reads meet the business need and the API supports reliable coverage. A hybrid can combine notifications with a separate reconciliation check, but adds operating work. Before choosing, define how fresh the data must be and how missing updates will be found.
Define data freshness, completeness and recovery first
Write down the decision that depends on the data. A dispatch dashboard used throughout the day may need a different freshness target from a next-morning management report. “Real time” is too vague to sign off.
Agree three separate targets:
- Freshness: how old may the displayed information be before it needs a warning?
- Completeness: must the destination show the current state, or retain every intermediate transition for audit?
- Recovery: after an interruption, how will the team identify the missing range and prove it was repaired?
These are requirements to agree, not CodeDrawn Digital performance promises. A current-state API may help repair today's order status without reconstructing every status the order passed through. If every transition matters, check for accessible event history and its retention rules before selecting a design.
When webhooks fit—and what to verify
Webhooks are a useful starting point when the source offers relevant events and updates need to start without waiting for the next scheduled check. You need a reachable receiving endpoint, a way to verify the sender and an operating plan for failed deliveries.
Check event coverage rather than assuming “supports webhooks” covers every change you need. Ask whether an event contains the required fields or whether the integration must fetch the current record separately. A webhook may reduce routine checking, but follow-up API reads still consume capacity.
Provider behavior matters. Stripe documents automatic delivery retries for up to three days in live mode, with different sandbox behavior, and says events are not guaranteed to arrive in generation order.[2] Its guide also calls for signature verification and a quick successful response before complex processing.[2] Those are Stripe-specific rules, not a universal webhook contract.
GitHub's webhook guidance calls for a webhook secret, HTTPS and a response within ten seconds, and includes guidance on missed deliveries.[1] Do not apply GitHub's deadline or recovery behavior to another platform without checking its documentation.
Separate “notification received” from “business record successfully updated.” Agree what the receiver must safely retain before acknowledging delivery, and how a failed background update becomes visible. A successful HTTP response is not proof that the destination now matches the source.
When scheduled polling fits—and what each run covers
Polling can be practical when the source has no suitable webhook, the receiving environment cannot accept inbound notifications, or the business can tolerate scheduled updates. It can also provide reconciliation alongside webhooks.
The hard part is not setting a timer. It is knowing what each run covers. Check whether the API supports a changed-since filter, a cursor, stable pagination or another documented way to resume. Establish how edits and deletions are represented; absence from one page is not sufficient evidence that a record was deleted.
If the endpoint provides HTTP validators, conditional requests can avoid downloading an unchanged representation. RFC 9110 defines If-None-Match and 304 Not Modified responses for conditional GET or HEAD requests.[3] This does not turn the endpoint into an event history or prove every intermediate change was captured.
Do not assume an unchanged response is free of rate-limit cost. GitHub recommends webhooks over polling and documents conditional requests for its own API.[4] Other providers can have different accounting and endpoint support. Check the actual service, credentials and API version involved.
A shorter interval creates more request pressure. Allow for pagination, catch-up reads and rate-limit pauses—not only the happy-path schedule. GitHub's guidance says to honor retry-after when rate limited.[4] A freshness target must account for such pauses; a configured schedule is not a delivery guarantee.
Webhooks vs polling: a decision worksheet
Use this in a brief or supplier discussion. Record evidence or mark an answer unknown.
| Decision | Webhooks | Scheduled polling | Evidence to request |
|---|---|---|---|
| Source support | Needs the right event coverage | Needs a readable API with sufficient coverage | Exact event and endpoint documentation |
| Freshness | Starts from a notification, subject to delivery and processing delays | Starts at a scheduled check, subject to runtime and source delays | Agreed stale-data threshold and measured checks |
| Receiver requirements | Reachable endpoint and sender verification | Outbound API access and protected credentials | Network and authentication design |
| Request pressure | Notifications may still trigger API reads | Runs and pages consume API capacity | Limit handling and catch-up capacity plan |
| Missing updates | Needs delivery-gap recovery | Needs complete scanning or resumable coverage | Reconciliation range, cursor and recovery evidence |
| Operational ownership | Receiver, failed deliveries and processing backlog | Scheduler, incomplete pages and failed runs | Named owner, alert destination and runbook |
Choose the simplest supported approach that meets the agreed targets and has a credible recovery path. A hybrid is worth considering when prompt notifications matter but completeness must be checked independently; it is not automatically right for every integration.
Hybrid example: reconciling order status between two apps
This is a hypothetical design illustration, not a client case, deployed integration or test result. It assumes the source offers order-change webhooks and an authenticated API that can enumerate orders changed within a documented time range. Verify those capabilities for the chosen service.
Suppose a business wants its support view to show a reasonably current order status while recovering changes missed during receiver downtime. The business and developer first agree the allowed staleness and recovery window.
A possible hybrid design is:
- A verified order-change notification starts processing for the relevant order. Where appropriate, the worker reads the authoritative current order rather than assuming arrival order equals business order.
- A scheduled reconciliation checks a documented overlapping change window. It follows every page and compares source records with the support view.
- The job advances its checkpoint only after the chosen range is fully handled. A failed page leaves a recoverable incomplete run, not a success marker.
- A difference is repaired or placed in a visible exception list. The run records its covered range, completion time and unresolved exceptions.
- If reconciliation stops completing or data becomes too old, the agreed operator receives an alert. An empty webhook queue alone is not evidence of health.
The overlap is a design precaution to validate against the source's timestamp and pagination semantics, not a claim that all APIs support this method. If the provider cannot enumerate historical changes, agree another repair method—such as a bounded full comparison—or record that complete recovery is not yet proved. Do not describe recovery as automatic when its required source data does not exist.
Duplicate handling matters in either design, but it is a separate decision from choosing the delivery mechanism. The safe retries guide for business automations covers that part of the brief.
Acceptance checks before integration sign-off
Ask the developer to run these against the selected provider and implementation, recording API/version details, environment, timestamps, sanitized evidence and actual results. These are proposed cases; they have not been executed for this article.
| Case | What the evidence should establish |
|---|---|
| Normal update | A known source change appears at the destination; observed delay is recorded against the agreed target |
| Receiver unavailable | A change made during downtime is recovered by the documented retry or reconciliation route, within its actual coverage |
| Reversed or duplicate notifications | The destination does not regress to an older state or repeat a consequential action |
| Poll fails on a later page | The run remains incomplete; restart does not silently skip unprocessed records |
| Conditional request returns unchanged | The cached representation is reused correctly without being mistaken for an event audit |
| Rate limit or expired credentials | Requests pause or fail safely, staleness is visible and the operator can identify the cause |
| Missing event or deleted record | The source-supported comparison detects the discrepancy, or the documented limitation is surfaced |
| Recovery exceeds history retention | The system reports an unproved gap and the runbook identifies the required manual or full-comparison step |
Define what counts as pass before the demonstration. “The job ran” is not the same as “the agreed data range is complete.” Keep sensitive payloads out of screenshots and logs; record only what the recovery proof requires under the business's data-handling rules.
Put an operating owner in the integration brief
Before commissioning the work, ask who maintains the endpoint or schedule, who investigates stale data, and who can authorize a repair. Agree the retained recovery evidence, access controls and what happens when provider behavior changes.
A useful brief ends with a delivery choice, its supporting documentation, the reconciliation method and a named operating responsibility. Unknown API capabilities are investigation items, not reasons to promise a result.
If you are planning a business app integration, outline the two systems, the records that must stay aligned, the acceptable delay and the person who handles exceptions. You can prepare a project brief for CodeDrawn Digital. The website helps prepare an email draft; it does not confirm that an email app opened, a message was sent or an inquiry was received.
Sources
Primary documentation checked on 29 October 2026. Provider examples describe documented behavior, not universal guarantees or CodeDrawn Digital implementation results. The worksheet and hypothetical example are editorial analysis, not executed tests.
[1] https:
[2] https:
[3] https:
[4] https: