Webhook Deliveries
This covers the outbound webhooks you register from Settings → Webhooks (/dashboard/settings/webhooks) to receive AgentLane’s own account events — not inbound Twilio/automation-engine callbacks. See API Access → Outbound Webhooks for the full event and retry reference.
Reading the Deliveries log
Each endpoint has a Deliveries log showing the most recent 50 attempts, each with a status:
| Status | Meaning |
|---|---|
delivered | Your endpoint returned a 2xx response |
pending | Still retrying — not yet exhausted its attempts |
failed | All attempts exhausted, or the endpoint was rejected outright before any attempt (e.g. by the SSRF check) |
“My endpoint shows failed deliveries”
Deliveries run on a queue: 5 attempts, exponential backoff starting at 5 seconds, with a 10-second request timeout per attempt. If your endpoint takes longer than 10 seconds to respond, or is down/unreachable, every attempt in that window fails and the delivery lands on failed once attempts are exhausted.
Also check: the endpoint URL is validated against private/internal IP ranges (SSRF protection) at both registration time and again at delivery time — if your endpoint’s DNS later resolves to a private address (e.g. behind a VPN or during infrastructure migration), deliveries to it stop outright rather than silently succeeding against the wrong target.
Use Send test on the endpoint to trigger a synthetic webhook.test event on demand, rather than waiting for a real account event to retest a fix.
“Signature verification fails on my end”
Recompute the HMAC exactly as AgentLane does:
body = the raw request body, exactly as received (do not re-serialize it)
timestamp = the t= value from the X-AgentLane-Signature header
signature = hex(HMAC_SHA256(your endpoint secret, `${timestamp}.${body}`))Compare your computed signature to the v1= value in the header. The most common mistakes:
- Re-serializing the JSON body before hashing (e.g. via a framework that auto-parses then re-stringifies it) — this can reorder keys or change whitespace, producing a different string than what was actually signed. Hash the raw bytes, not a reparsed object.
- Using the wrong secret — the signing secret is shown exactly once, at registration time. If it wasn’t saved then, there’s no way to retrieve it again; delete the endpoint and re-register to get a new one.
- Rejecting on clock drift — a reasonable replay-window check (rejecting a
tthat’s unreasonably old) is your own responsibility, same as with Stripe’s convention this follows; don’t reject based on a strict equality check against “now.”
Related
- API Access → Outbound Webhooks — full event type list and the exact signing recipe
- Credentials & permissions — if the issue is actually a BYOK credential, not a webhook