Skip to main content
Delivery works; the delivery history does not. A production walk on 2026-07-19 (v0.12.15) delivered meeting.status_change, meeting.completed and bot.failed to an external webhook.site endpoint — the receiver’s inbox and meeting-api’s own delivery-outcome log matched one-for-one at code=200. What is still broken is the user-facing Delivery History, which reads a store those deliveries were never written to and so shows none of them (#841, open). Deliveries now succeed silently — the exact inversion of #815, where they failed silently.

​
What exists in code

  • Self-serve configuration (PUT /user/webhook): URL, secret, and event selection, with the secret masked on read-back.
  • The webhook.v1 delivery module: HMAC-signed payloads with a retry queue.
Don’t have a key yet? Hosted: sign in at vexa.ai/signin with a Google account and copy your key from your account page — free credit, no card required. Self-hosted: make all prints a key when the stack comes up.

​
What is proven, and what is not

  • Live delivery — proven. Owner-witnessed production walk, 2026-07-19: POSTs arrived at an external webhook.site inbox from production IPs, one per walk event, matched one-for-one by meeting-api’s delivery-outcome log at code=200.
  • Delivery History — broken. The user-facing history reads a store real deliveries were never written to, so it lists none of them (#841, open). Do not read an empty history as “nothing was delivered.”
  • CI does not exercise the network leg. The module and eval tests drive the real WebhookSink against a fake in-memory receiver, so a regression in the transport itself would not be caught by tests — only by another live walk.
  • No settings UI — configuration is API-only (PUT /user/webhook).
  • Exactly-once emission (#519) and outage-durable retry (#520) both closed as completed in July.
The live status row for this feature is maintained on Roadmap → Status.