Two ways to learn that something changed
Polling asks a system for its latest state at intervals. A webhook lets a provider notify an endpoint when an event occurs. The choice depends on what the provider supports, how quickly the business needs an update and how you will recover when a message is missed. Many integrations benefit from both.
Use shipment tracking as an example
A customer may not need a fresh carrier request every time they open a page. Your system can display the most recently confirmed status and its timestamp. Updates can arrive through notifications or scheduled checks. The important product decision is how old a status may be before you tell the user it needs refreshing.
Make webhook handling defensive
Follow the provider’s signature verification procedure before accepting an event. Treat delivery as potentially repeated and out of order. Record a stable event identifier, validate the payload and make processing safe to retry. A notification is evidence to handle, not permission to trust every field or perform arbitrary actions.
Avoid wasteful polling
Choose intervals based on business urgency and provider limits. A completed shipment does not need the same checking frequency as an active delivery. Back off after failures and show the last successful update time. Continuous aggressive retries can worsen an outage and consume resources without producing new information.
Add reconciliation
Schedule a way to compare your records with the provider’s authoritative state. This helps recover from interruptions and missed notifications. Test duplicate events, delayed events and unavailable endpoints before launch. Document which system owns the final status so support staff know where to investigate a disagreement.
Published by DevMania with AI assistance. Examples illustrate planning approaches and do not claim client results. Check current provider documentation before implementing product-specific features.