Migrating from Svix
The signature scheme is the same on both sides, which removes the part that usually breaks. What is left is inventory, and two decisions.
In short
- Consumers verifying Standard Webhooks signatures need no change — Svix wrote that spec and we implement both of its schemes.
- Destinations, secrets and event types are the inventory to move.
- The portal is no longer a blocker: ours is embeddable and white-label on every plan, and under a consumer grant your customers create and manage their own endpoints — the last capability that used to be a reason to stay.
- Move per tenant, and keep Svix able to deliver until the batch is proven.
How to read this page. Every claim about another product below was read off that company's own public pages on 20 August 2026, and each one links to the page it came from — check it yourself, that is what the links are for. Pricing and features move without anyone telling us, so our build fails if this page goes more than 120 days without a re-check. Everything stated about HookGet is something you can verify in the product today, including the rows where we lose. If we have something wrong, tell us and it is fixed the same day.
What transfers cleanly
| Thing | How it moves |
|---|---|
| Signature verification | Unchanged. Both sides are Standard Webhooks |
| Destination URLs | Recreated through POST /v1/endpoints |
| Event types | Recreated, with an optional JSON Schema per type |
| Event type filters per destination | Same idea: a list of types on the endpoint — plus payload filters, which Svix has no equivalent for |
| Secrets | New secret per destination, or rotate onto ours during an overlap window |
| The consumer portal | Embed ours where theirs was: POST /v1/portal-links with embed: true returns an iframe snippet carrying your logo and colour |
POST /hooks HTTP/1.1webhook-id: msg_01J8ZQ3F9VBAQ4E1S0TZY6P8YV
Stable across every retry — use it as your idempotency keywebhook-timestamp: 1755264000
Outside a 5-minute window, refuse it — that is the replay guardwebhook-signature: v1,ZeHt1v… v1a,mK4p…
HMAC and ed25519 side by side during a scheme change, space separated{"type":"order.created","timestamp":"…","data":{…}}
Signed content is id.timestamp.body — the exact bytes, never a re-serialisationWhat needs a decision
- Which portal grants to mint. Read-only is the default here. If your
users administer their endpoints themselves in Svix today, mint their links with the
manageandcreateflags and aconsumer_id— they can then add endpoints, move them, rotate keys and pause deliveries, and every link minted for the same consumer sees the endpoints that consumer created.
- Transformations. Declarative reshaping (pick, omit, rename, set, unwrap, wrap) moves onto the endpoint here. Logic that genuinely needs JavaScript has to move into your publisher before you migrate — we do not run customer code, deliberately.
- Compliance and SLA. If a SOC 2 report or a contractual uptime figure is in your customer contracts, we have neither. Svix publishes both.
A safe order of operations
- Open a HookGet account and prove one delivery end to end on the test project.
- Recreate destinations for one small tenant. Keep Svix running.
- Publish to both systems for that tenant and compare the delivery logs.
- Stop publishing to Svix for that tenant. Watch the timeline for a day.
- Repeat in batches, largest last.
- Only then remove the old integration from your publisher.
Start delivering webhooks today
Step one is an account and one test delivery. Test traffic is never metered.
Create a free account See pricing
10,000 deliveries a month free, no credit card. The free tier blocks rather than bills, so trying the product cannot produce an invoice — which is not true of every free tier in this category.
Verified 20 August 2026 against: Svix pricing · Svix retry schedule. Re-checked at least every 120 days.