agent timed out waiting for a webhook that arrived on the wrong endpoint
Recovers from webhooks arriving on the wrong endpoint without losing payment state. Use when a wait times out but the event later shows up elsewhere, or handlers are registered on multiple URLs. Not for missing webhooks entirely.
agent timed out waiting for a webhook that arrived on the wrong endpoint
TL;DR
Don't wait on one endpoint: poll the provider's event list as a fallback, and route all webhook URLs to a single handler that dedupes by event id. If the event landed elsewhere, replay it into the canonical handler. One handler, many URLs, zero lost events.
agent timed out waiting for a webhook that arrived on the wrong endpointFix it
- Unify the handler. Point every webhook URL (old, new, per-environment) at one ingestion function that verifies the signature and dedupes on event id. Success check: sending the same event to two URLs processes it exactly once.
- Add an event-list fallback. When the wait times out, list recent events filtered by type and object id, then process any matches. Success check: a staging run with the webhook URL broken still completes via the fallback.
- Bound the wait. Wait at most a few minutes for the push, then fall back to the event list; never block a payment flow indefinitely on a webhook. Success check: worst-case completion time in staging is wait-cap plus one list call.
- Clean up stale endpoints. Delete or disable webhook endpoints that shouldn't receive traffic, and document the canonical one. Success check: the provider dashboard shows one active endpoint per environment.
When this applies
- An agent waits for a webhook (payment success, invoice paid) and times out, but the event exists in the provider dashboard.
- Multiple webhook URLs exist from migrations, renames, or per-agent setups.
When it doesn't
- No event was ever generated; check whether the payment actually completed.
- Signature verification fails everywhere; that is a secret mismatch, not routing.
Compatibility
- Pattern: agent payment flows on Stripe (Events API + webhook endpoints), Adyen notifications, or any provider with push events plus an event-list API.
- Stripe API 2024-06 and later; the unify-and-fallback pattern is provider-agnostic.
Variant: test-mode events went to the live endpoint
Mode mismatch across environments. Same fix plus per-environment endpoints and secrets, never shared.
Variant: agent waited on the wrong event type
The flow waited for charge.succeeded but the integration emits payment_intent.succeeded. Same fix with emphasis on step 2: the event-list fallback with the right type filter catches it.
Why it happens
Webhook URLs accumulate: migrations, new agents, renamed services. The provider delivers to whichever endpoint is registered, which is often not the one the waiting agent is listening on. The agent times out on silence while the event sits processed (or unprocessed) elsewhere.
Edge cases
- Out-of-order events: process by event creation time, and make handlers idempotent so a replayed older event can't regress state.
- Don't auto-retry the wait in a tight loop; the fallback list call is the retry.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_829NaIlA1C52j0UnNxAVPg