Svix alternatives for outbound agent event delivery

You emit invoice.paid and Svix retries a customer endpoint for hours. That part works. Separately, an inbound Stripe webhook wakes your agent, and the agent calls your own ledger. Svix is not on that second path. Treating them as one product leaves the ledger call unchecked.

This post separates outbound event delivery from an inbound trigger that makes an agent call an API.

What Svix delivers and what it retries

Svix sends messages to endpoints your customers register. The retry schedule, updated 9 October 2026, attempts immediately, then 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, and another 10 hours. A 2xx within 30 seconds is success. Anything else, including a redirect, is a failure. After the schedule, the attempt is exhausted. An endpoint that fails for a defined multi-day pattern can be disabled.

Idempotency covers two different things. A POST to the Svix API can send Idempotency-Key and get the same response for up to 12 hours. Delivery to customers is at least once. The webhook-id header stays the same across retries of one message. The receiver must store that id and skip a second process. Svix does not promise the receiver runs once.

The pricing page lists a free tier up to 50,000 messages a month, 50 messages a second, and 7-day payload retention. Basic starts at $20 a month with a 99.9 percent SLA and 30-day retention. Professional starts at $490 a month with a 99.99 percent SLA, 90-day retention, and static source IPs. Retries are free. Filtered messages that never go to an endpoint are not billed. Attempted messages are.

Where outbound delivery wins

Use Svix when your product emits events and customers consume them. You want the portal, the signature, the retry schedule, and a replay of failed messages from the customer portal. Webhook infrastructure for agents is the wider comparison. Svix is the outbound half.

You do not use it to decide whether your agent may call a provider after some other system calls you. That hop never enters Svix unless you built it that way.

Inbound triggers that start a provider call

An inbound webhook is a trigger. The agent then chooses a method. The webhook-id on a message you sent to a customer does not label that outbound provider call. If your receiver is an agent, store the inbound id before any tool runs, the same way a Svix customer should store webhook-id.

Then allow the methods that trigger may cause. Swytchcode blocks a method you did not add, and a policy can block a bad argument on a method you did add. On the October 2026 pricing page, Free includes allow and deny. Policy as code is that file. Multi-tenant OAuth matters if each customer has their own provider account and the event must call the right one.

Keep Svix on the events you publish. Check the call your agent makes when someone else's event arrives.

Customers who consume invoice.paid should store webhook-id and ignore the 5-minute retry. That is their job, and Svix documents it. Your job starts when a different inbound event, such as a payment provider calling you, should cause your agent to mark an invoice paid in your ledger. Svix's retry clock does not cover that inbound request. If your agent calls the ledger on every inbound attempt, you will mark the invoice twice while Svix is busy retrying someone else's endpoint. Separate the diagrams. One arrow leaves you, through Svix, to a customer URL. The other arrow enters you, wakes an agent, and leaves again to a provider. Only the second arrow needs an allowlist. Only the first arrow needs the Svix schedule. If you diagram only one of them, you will either retry customer traffic by hand or let an agent call a provider on every inbound duplicate. A customer endpoint that returns 200 before it finishes the work will not be retried, and that event is gone.

Store the id, then allow one method

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 provider the agent calls after an inbound event. Add one method. Skip the call if you have already handled that inbound id.

swy search <provider>
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.

swy auth connect <provider>
swy policy validate

Publish customer events through Svix. When an inbound event makes your agent call a provider, require a stored id and an enabled method. The Svix retry clock covers the customer endpoint, not that later provider call. Store the inbound id before you allow the method.

Related reading

• Policy as code. The outbound retry and the inbound tool call need different checks.
• A credential per customer. The event must select the right connected account.
• Log every API call an agent makes. Message attempts and provider calls are different counts.
• Human approval. A retried inbound event should not send twice.

FAQ

Does Svix charge for retries?

No. The pricing page says retries are free. You pay for attempted or transformed messages. Messages filtered because there is no endpoint are not counted.

How long is a Svix idempotency key remembered?

For POST requests to the Svix API, up to 12 hours, for the same auth token and key. That does not dedupe what your customer's server does. Receivers use webhook-id, which stays stable across delivery retries.

Can I use Svix as the trigger for my agent?

Only for events you send through Svix. It is an outbound delivery system. An inbound provider webhook that should wake an agent needs its own receiver, its own id store, and its own allowlist.

What is the retry schedule?

Immediately, 5 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, and another 10 hours. Enterprise can customize it. A receiver can stop further attempts with the webhook-delivery: abort-message header.