Hookdeck alternatives for replaying agent webhooks

A provider webhook fails, Hookdeck retries it, and your agent books the same meeting twice. You replay yesterday's traffic into a new connection after a fix. The agent treats the replay as a new instruction and sends another email.

This post shows what Hookdeck's retry, dedupe, and replay actually do, and what you still check when the consumer is an agent.

Retry, replay, and dedupe

Retries re-run an existing event to the same destination. Automatic retries stop at 50. Manual retries are unlimited. Requests say a replay creates a new request and a new event per connection. Filters and dedupe run again. Verification is not run again. A replay counts toward usage. Deduping applies to replays, so a replay inside the dedupe window can be ignored as a duplicate.

Deduplication uses a window from 1 second to 1 hour. You can hash the whole payload or selected fields. Hookdeck says this is best effort and not guaranteed. The destination still needs its own idempotent handler. Ignored events are not delivered.

The pricing page lists Developer at $0 with up to 10,000 events and 3-day retention. Team starts at $39 a month with 7-day retention. Growth starts at $499 a month with 30-day retention, SSO, and HIPAA. Each plan includes 10,000 events. More delivered events are $3 per 100,000 up to 5 million a month, then lower. Retries are included in event pricing. A replay that creates events is new usage.

Where the gateway earns its fee

Use Hookdeck when many providers push events at you and you need a queue, a retry, a signature check, and a way to backfill a new consumer. The 50-try cap and the dead letter are the product. Webhook infrastructure for agents compares that layer.

You want it in front of an HTTP handler that records the event id and returns quickly. You do not want the agent to treat every delivery attempt as a fresh user request.

When the consumer is an agent

An agent does not have the habit of a normal handler. It may call a provider because the payload arrived, not because it stored x-hookdeck-eventid and skipped a duplicate. A retry then becomes a second tool call. A replay into a new connection becomes a backlog of tool calls.

Store the event id before you let the model act. Hookdeck tells you to do that. Then allow only the methods that event should trigger. Swytchcode can block a write that is not on the list, even if the model wants to "follow the webhook." On the October 2026 pricing page, allow and deny are on every plan. Policy as code is the file. Logging the call shows whether the replay produced one provider call or many.

Dedupe will not save you if the window is shorter than your outage, or if the replay is outside the window on purpose. The handler and the allowlist still run.

Treat a booking webhook as the test. Attempt one fails because your handler timed out after the agent already created the meeting. Attempt two delivers the same event id. If the handler checks the id, it returns 200 and does nothing. If the agent is the handler, it may create meeting two. A replay the next day, outside a one-hour dedupe window, is a new event with the same provider payload and a new Hookdeck id. Your store has to understand both ids: the gateway id for delivery, and the provider's booking id for the business action. Skip when either one was already acted on. The gateway cannot see that your agent already called the calendar. Retention decides how long you can even replay: 3 days on Developer, 7 on Team, 30 on Growth. After that the payload is gone and the duplicate, if you made one, is only in your own log.

Record the event, then allow the call

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry for the system the agent calls after a webhook. Add only those methods. In the handler, skip work you have already done for that Hookdeck event id.

swy search <system>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. Validate the policy on the writes that remain.

swy auth connect <provider>
swy policy validate

Keep Hookdeck for delivery, retry, and replay. Make the agent act once per event id, and only through methods you enabled. A second delivery of the same booking should return success and should do no new calendar work. Check the event id before the agent runs.

Related reading

• Policy as code. The event can arrive twice. The write still has to pass.
• Log every API call an agent makes. Count provider calls caused by a replay.
• Human approval. A replayed webhook should not auto-approve a send.
• Credential brokering. The destination secret and the provider key are different secrets.

FAQ

What is the difference between a Hookdeck retry and a replay?

A retry adds an attempt on the same event, to the same destination. A replay creates a new request and new events, can target other connections, and counts as usage. Deduping can ignore a replay that falls inside the window.

Are Hookdeck retries billed separately?

The pricing page says retries are included in event pricing. Replays that create new events count as delivered traffic. A replay that produces no events counts as a discarded request.

Is deduplication enough if the consumer is an agent?

No. The window maxes at 1 hour, and Hookdeck says dedupe is best effort. Store the event id in your handler and skip a second side effect. Also limit which methods the agent may call.

How far back can I replay?

Only while the payload is inside your retention window. Developer retention is 3 days, Team is 7, Growth is 30. A replay of archived data returns HTTP 409.