Connect application events to business records
Webhooks notify a receiving service when a source application records an event. In Uplyst, an invoice update, changed order or service event can be related to the relevant customer, transaction and workflow without repeatedly polling for every change.
The provider defines event types, payloads, signing methods, retry rules and delivery identifiers. The connection follows those rules and subscribes to the events needed by the business process.
Verify the source of each delivery
Signature verification follows the sending application's documented method. Providers that sign the raw request body require those original bytes for verification. Secrets, algorithms and signature formats vary between services, so they belong to the individual connection configuration.
Separate delivery from business processing
Durable receipt allows the endpoint to respond promptly while longer processing continues. Accepted, processing, completed and failed states make progress visible and support recovery after an interruption.
A repeated event can be linked to its existing processing record. Any resulting external action also needs its own duplicate protection so a delivery retry cannot repeat a completed business operation.
Recognise repeated and delayed events
Webhook deliveries can repeat or arrive out of order. Authenticated event identity and processing history help recognise work already accepted, while source timestamps and resource versions help interpret its place in the business sequence.
A valid signature confirms authenticity; it does not establish that an event is new. Signed timestamps, where supplied, support freshness checks. Replay handling must match the information the provider actually authenticates.
| Check | Question answered |
|---|---|
| Signature verification | Does the body match the expected signing contract? |
| Provider-defined event identity and deduplication scope | Has this verified work already been accepted? |
| Supported freshness check | Is this delivery within the accepted time policy? |
| Schema and business validation | Can this event be processed for the intended purpose? |
Recover events that need attention
Invalid signatures, changed payloads and unavailable downstream services have different consequences. Rejected deliveries remain separate from events already accepted for processing. Retained failure information allows authorised replay and reconciliation with the source application.