A Developer webhook is the AON-to-Developer delivery direction for a supported Protocol v1.0 conversion event.
AON sends the event to the HTTPS endpoint configured for a Developer Application with version, key, timestamp, and HMAC signature headers. The receiver verifies the exact raw request before parsing, deduplicates using the documented event identity and body digest, and treats the fixed retry schedule as part of the delivery contract.
Developer webhooks in AON
AON uses Developer webhooks to deliver supported conversion evidence to application-owned endpoints without giving the receiver authority over checkout or settlement. Signed requests, durable idempotency, and fixed retries define the delivery contract separately from Partner postback intake.
Read the Webhook Protocol v1.0How a Developer webhook works
Configure the receiver
A Developer Application stores the HTTPS callback endpoint and the active callback key generation.
Sign the delivery
AON sends the exact v1.0 headers and signs the request target, raw body, and attempt timestamp.
Verify before parsing
The receiver rejects missing or duplicate headers, invalid timestamps, signature failures, and malformed payloads before side effects.
Apply idempotently
The receiver stores the event identity and raw-body digest in the same transaction as its business effect.
Handle retries
A 2xx completes delivery; timeout, 3xx, and other non-2xx results follow the fixed five-attempt schedule.
Webhook reliability boundaries
The delivery contract separates wire authenticity, business idempotency, retry behavior, and runtime health.
| Concept | Meaning |
|---|---|
| Wire authenticity | The receiver verifies the exact request-target, raw body, timestamp, key id, and HMAC signature. |
| Event idempotency | The same event and body can safely return 2xx without repeating a business effect; the same event with a different body is a conflict. |
| Retry lifecycle | The event id and raw body stay frozen across five attempts while each attempt receives a fresh timestamp and signature. |
| Operational evidence | Configuration is not delivery health; runtime observation and a signed canary provide the evidence that delivery works. |
- A Developer webhook is not a Partner postback and does not receive Partner Offer Fetch credentials.
- The webhook reports a conversion event; it is not a checkout confirmation, payment authorization, or settlement result.
- A 2xx response confirms delivery completion, not necessarily that the downstream business outcome is payable.
Developer webhook vs Partner postback
A Developer webhook sends an AON-generated conversion event to an application receiver. A Partner postback sends a Provider-reported downstream event into AON. They have different directions, credentials, payloads, and delivery responsibilities. See the Postback definition.
Example in practice
A Developer Application receives a signed conversion webhook, verifies the raw body and HMAC, checks its durable (agent_id, event_id) record, applies the business effect once, and returns 2xx. A repeated delivery with the same body returns 2xx without a duplicate effect.
Common questions about developer webhook
Who sends a Developer webhook?
AON sends it to the HTTPS endpoint configured for a Developer Application.
How should a receiver verify a webhook?
Reject missing or duplicate security headers, verify the exact raw request with the active key and HMAC signature, then parse and validate the closed conversion payload.
How many times can AON deliver a webhook?
AON uses a fixed five-attempt ladder. Any 2xx completes delivery; timeout, 3xx, and other non-2xx responses can trigger the remaining attempts.
Is a webhook the same as a Partner postback?
No. A webhook is AON-to-Developer delivery. A Partner postback is Provider-to-AON conversion intake and has a separate endpoint and security boundary.
Sources
- AON Developer WebhooksAON documentation
- AON Partner postbacksAON documentation
- AgentOffer Protocol v1.0 postback specificationAON specification