Email glossary · Practical guide
Webhook: an event notification with a receiver you must operate
A webhook sends an event notification to a configured HTTP endpoint. Its reliability, authentication and retry behavior depend on the actual sender and receiver implementations.
Reviewed · Examples are illustrative
Who this helps: Readers checking a term before making an outreach or mailbox decision.
Meaning and common confusion
The receiving service must verify the request, validate the payload and decide what action is authorized. A successful HTTP response does not prove the downstream business action completed. Zintara's current general webhooks are best-effort notifications, so they should not be treated as a complete replayable source of truth.
Worked example
This is a synthetic illustration, not a customer result or a live configuration to copy.
Event occurs → sender posts notification → receiver verifies and stores work
HTTP success: receiver accepted the request
Separate evidence: downstream action completed
Missing notification: requires reconciliation, not an assumption that no event occurred.Checks to make
- Verify signatures on the exact received body.
- Handle duplicates without repeating business side effects.
- Record failures and reconcile important state separately.
Next step and limits
Use the Zintara schema and delivery-failure guides before implementing a receiver. Do not expose secrets in URLs or treat a timestamp as a guaranteed unique event identifier. Subscribe only to event names the deployed product supports.
Source: Zintara product context for this operational definition
Source references
Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.
Related guides
- Zintara webhook event schema and signature reference →
- Zintara webhook delivery failures: best-effort dispatch and recovery boundaries →