Registering a webhook URL is the short part. The larger task is deciding what your system does when an event arrives twice, the PDF is not ready yet or the receiver stores the message but loses its response.
Those are ordinary integration conditions, not exotic edge cases. A useful webhook design makes them visible from the start. It separates accepting a delivery from completing the business action that delivery triggers.
Authenticate the message before trusting it
Waiver.com signs deliveries using the endpoint's secret and the exact request bytes. Verify the signature and timestamp before treating the payload as authentic. Parsing and reserializing JSON first can change the bytes and invalidate an otherwise correct message.
The verification guide includes a Node.js example. Keep the signing secret in server configuration and out of logs. It is separate from the bearer key your worker uses to retrieve record details.
Accept durably before acknowledging
A common shortcut is to return success immediately and process the event in memory afterward. If the process stops between those steps, the sender believes the work was accepted while the receiver has lost it.
Store the delivery in a persistent queue or durable inbox before returning 2xx. Keep the receipt path short, then let a worker perform slower tasks such as retrieving a record or updating another system. The distinction gives both systems an honest account of what has happened.
Deduplicate transport and business actions
Retries for one delivery share a delivery ID. Store that identity so a repeated attempt does not create another queue item or duplicate side effect. Use an atomic acceptance pattern where possible so recording the ID and storing the work cannot drift apart.
Manual replay is a different case: it creates a new delivery ID for the historical event. Your receiver should accept the new transport attempt, while the business operation still needs to account for work already performed. The duplicate-handling guide explains that distinction.
Expect a signed record before its PDF
A signed event can arrive while PDF rendering is pending. That is not a reason to submit the waiver again. Retrieve the record, observe file readiness and schedule the download appropriately.
An integration that treats every missing PDF as a failed signature can create unnecessary work and confusing participant histories. Keep the signed record ID, file state and download attempts separate in your worker.
Observe the destination, not only the delivery
A successful webhook response means the receiver accepted the message. It does not prove that the downstream CRM, reporting database or file store was updated. Track worker completion and keep failed jobs reviewable.
When recovery is needed, inspect the original failure before replaying the delivery. Fixing the cause first makes replay useful. Sending the same historical event into the same broken path simply creates another failure record.
The developer center brings these pieces together in the webhook overview. Start with one event and one dependable destination, then expand after the acceptance and recovery paths are clear.