Webhook
Webhook explained
A suits a clearly defined trigger, such as a confirmed status change. Specify which message and information are expected and which action may follow. An observed activity is not automatically a qualified contact or permission to send marketing.
Plan for delays and outages. Messages may be redelivered depending on the provider; retry and ordering rules differ. The destination should recognise duplicate processing and handle missing or delayed events. Check these rules in the relevant documentation.
Origin and content also require checking. Depending on the system, signatures, delivery identifiers and appropriate access controls can help. An acknowledgement may precede actual processing. Monitor the business outcome alongside the HTTP response.
A webhook is not the same as a Conversions API. It describes a triggering and delivery mechanism, whereas an API broadly defines features and rules for software access. The two can work together. Neither term guarantees complete tracking or legally permissible data use.
Examples
Hypothetical application
A booking system notifies a customer portal of a confirmed appointment change. After a connection interruption, the same message is delivered again. The portal recognises the identifier and updates the appointment once. A separate test checks what happens when an older status message arrives late.
Key Points
- Define the trigger, message and permitted follow-up action.
- Observe delivery and processing separately.
- Test repeated and delayed messages.
- Use provider-specific rules instead of general real-time guarantees.
Practical application
Define required events and their consequences. Test normal, duplicate, delayed and failed deliveries through to the actual outcome.
Useful measures
Processed events
Compare delivery status with the actual business outcome.
Processing duration
Investigate time from the trigger to the confirmed result.
Retry and error handling
Check that repeated, delayed and missing messages are handled in a controlled way.
Common mistakes
- Treating acknowledgement as a fully completed operation.
- Assuming guaranteed delivery order without provider evidence.
- Equating webhooks with complete tracking independent of consent.
Sources and context
- GitHub Docs: About webhooks
Explains event-driven delivery and its difference from repeated polling.
- GitHub Docs: Webhook best practices
Concrete guidance on origin checks, delivery identifiers and redelivery; GitHub-specific timing limits are not universal rules.
Frequently Asked Questions about Webhook
No. The network, provider or destination may delay or prevent delivery. Plan the required handling.
Otherwise the same operation could be performed more than once. Appropriate identifiers and processing rules help handle repetition in a controlled way.
No. A targeted request may still be needed, for example to check current status or reconcile missing information.
Loading related terms…
All TermsArticles about Webhook
Marketing as an Operating Discipline: Why Almost Every CMO Talks About AI and Few Have Built It
The gap between intent and execution is not a technology problem, it is an operating model problem. How to move marketing from a project organisation to an operating discipline with systems, roles and cadence.
GEO in practice: Customer questions and evidence
A practical GEO review: choose customer questions, check content gaps and technology, add evidence and assess suitable enquiries.
AI as a Conversation Partner
When people ask AI for advice, it's not about technology – it's about trust. What brands should learn from this.