A report reviewed each morning and an order status awaited by customer-service staff do not necessarily need the same update speed. Before choosing webhooks or scheduled API polling, identify when delayed information becomes a business problem. “Real-time” alone defines neither integration scope nor acceptance.
Record the information, its source, its user and the decision it supports. Agree on an appropriate delay limit, its measurement and what users see when data becomes stale. A notification may arrive quickly while processing or display lags; operations need a result they can rely on.
Two ways to initiate an update
GitHub documentation explains that a webhook sends notifications to a receiving system for subscribed events, whereas polling queries an interface periodically. Events may reduce unnecessary queries, but selection depends on source capabilities and information use, not technology names alone.
If the source lacks the required event or access, a “live” arrow in a proposal does not resolve the limitation. Request evidence of availability in the actual version and account. If on-demand reads suffice for a small set of records, include that possibility among suitable alternatives too.
A fictional example: tracking print-shop production
A print shop wants follow-up staff to see production status in a portal and management to receive a morning summary. Staff may need fresher information than the aggregate report. The example assumes no particular source-system capability: the supplier must verify it and propose a route for each use, without real customer data.
Define the status first: is it the latest step recorded in production software or an employee's confirmation that an order is ready for collection? A value can arrive quickly and still be unsuitable if its meaning differs. Fixing that meaning prevents a speed discussion from concealing a problem with the decision's information source.
A timing sheet before integration pricing
| The organization defines | The supplier explains | Acceptance test |
|---|---|---|
| Impact of a delayed production status. | Available event or query and processing path. | Source change time and user-visible result time. |
| When management needs its summary. | Read schedule and report data cutoff. | Whether the report covers the agreed period without mixing times. |
| Order volume and peak periods. | Interface and resource limits, with unmeasured assumptions. | Representative test load within authorized limits. |
| The response to stale data. | Status indication, gap detection and follow-up. | An arranged interruption and visible recovery of missed changes. |
This editorial sheet does not prescribe one response time for every project. Separate measurements from estimates and identify where delay measurement starts and ends. Measuring message arrival at a server differs from measuring the result on the employee's operational screen.
Notifications do not remove recovery needs
Shopify states that webhook delivery and order are not guaranteed and recommends periodic reconciliation rather than relying on events alone. These are documented limits for a particular provider. Ask about the actual source's guarantees and detection of missing or delayed data instead of applying one platform's behavior universally.
A suitable design may combine notifications for routine updates with periodic reconciliation reads. Identify which data is compared, the comparison window and who resolves differences. For duplicate effects and unknown outcomes, consult retry acceptance tests, rather than reducing those questions to sending speed.
Review operating cost alongside development cost
Overly frequent reads can consume interface quotas without useful benefit, while event processing needs reception, monitoring and maintenance. Request an explanation of operating components and limits instead of assuming one method is always free or cheaper. Do not invent volumes or consumption prices the project has not measured or the provider has not confirmed.
Also ask what happens if interface limits change or the schedule stops, and how the owner knows the latest update is stale. Print-shop users should distinguish “the order remains in production” from “the current status is unknown because integration stopped,” so apparently fresh information does not drive a mistaken decision.
The integration discovery map helps prepare systems and fields. Attach the timing sheet when discussing systems integration with Nextwave, so comparison considers delay impact, available capabilities and acceptance evidence rather than “instant synchronization” alone.
What the documentation establishes
GitHub's webhook explanation and Shopify's event guide were opened on 4 November 2026. The example and sheet are editorial material, without a service agreement or timing guarantee. AI assisted preparation, with meaning, source and translation review.
