Webhooks as a service
Webhooks that arrive.
Publish an event once. HookGet stores it, signs it, delivers it to your customers' endpoints, retries what fails, keeps what cannot be delivered, and shows you every attempt — so a delivery problem is something you can see instead of something a customer reports.
No credit card. A live project and a test project from the first minute.
-
Attempt 1failed
-
Attempt 2failed
-
Attempt 3delivered
What you get for one POST
The pipeline behind a single publish call, in the order it runs.
Durable first
The event is written before it is acknowledged. The queue is derived from storage, not the other way round, so losing the queue costs throughput and not events.
Signed on the way out
Every delivery carries a Standard Webhooks signature over the raw bytes, with an id that stays constant across retries — the natural idempotency key for the consumer.
Retried on a schedule you choose
Eight attempts across about a day by default, and a custom schedule per endpoint when a destination needs a different rhythm.
Kept when it fails
Exhausted deliveries land in a dead-letter queue you can inspect and replay, with the original event id preserved so a consumer that dedupes will not double-process.
Disabled before it hurts
A destination that keeps failing is taken out automatically, and the fact is published as an event you can subscribe to. Recovery is one call, and it replays what died.
Visible while it happens
Every attempt is on a timeline with its status, latency and the first kilobyte the destination answered. Debugging is reading, not guessing.
Publishing is one request
Anything else the product does is available on the same API with the same key.
curl -X POST https://api.hookget.com/v1/events \
-H "authorization: Bearer $HOOKGET_KEY" \
-H "content-type: application/json" \
-d '{"type":"order.created","payload":{"id":"ord_10241","total":149.9}}'
# 202 Accepted — the event is stored, and fan-out has started
# {"id":"msg_01M0…","type":"order.created","units":1,"endpoints":2}The response returns only after the event is durable, and it tells you what it will be metered as. On the consumer side, verification is a short function — see the signature guide.
Events can come in, too
Fifteen providers are verified on the way in, so a third-party webhook becomes an event in your own catalogue with the same retries, the same log and the same replay.
Verified, not just accepted
Nothing enters the pipeline before the provider's own signature checks out over the raw request body — GitHub, Shopify, Stripe, Standard Webhooks and more.
Deduplicated on their id
Providers redeliver. The provider's own delivery id is the dedupe key, so a redelivery does not become a second event on your side.
Token in a header, never a query
Providers without a signature authenticate with a token — accepted in the header only. Query strings end up in logs, referrers and history.
The delivery contract, in one table
Defaults, and what you can change.
| Behaviour | What HookGet does |
|---|---|
| Retry schedule | 8 attempts over about 21 hours, and the schedule is settable per endpoint |
| Acknowledgement | 202 only after the event is written; the queue is derived from storage |
| Signature | Standard Webhooks over the raw bytes, with overlapping rotation so nothing drops |
| Idempotency | A publish key deduplicates producers; the delivery id is stable across retries for consumers |
| Dead letters | Kept and replayable, with the original event id preserved |
| Auto-disable | 50 consecutive failures, or immediately on 410 Gone; announced as an event |
| Rate limiting | A token bucket per endpoint, plus a limit per project and per inbound source |
| Ordering | Per endpoint, by sharding — deliveries to one destination keep their order |
| Egress safety | Private and metadata addresses refused, in code and again at the network layer |
| Metering | Every started 64KB of payload is one unit, returned on every publish |
What it does not do yet
Stated plainly, because finding out later is worse than reading it now.
- No payload transformations. Events are delivered as published. Reshaping per destination is not available.
- No embeddable customer portal yet. Your team gets a dashboard; your customers do not get a self-serve page of their own.
- No local tunnel CLI. Point a test endpoint at a public URL or a tunnel of your own choosing.
- No non-HTTP destinations. Delivery is HTTPS; queues and buses are not destinations.
- No mTLS or OAuth2 to destinations. Signatures and custom headers, not client certificates.
- No SOC 2 report. EU residency and the practices on the security page are what exists today.
If one of these is a requirement, the comparison pages say who does have it.
Questions
What is a webhook delivery service?
It is the layer between "our system produced an event" and "our customer's server acknowledged it". It stores the event, signs it, delivers it, retries it on failure, keeps what could not be delivered, and shows an operator exactly what happened to each attempt. Teams usually write the first version themselves and rewrite it after the first outage.
How is this different from a queue?
A queue moves work between systems you control. A webhook service delivers to endpoints you do not control: they go down, they answer slowly, they change their TLS, they return 410 when a customer removes an integration. The retry policy, the signature contract, the circuit breaker and the per-destination rate limit all exist because the far side is someone else's server.
Do I have to change how my consumers verify signatures?
HookGet signs with Standard Webhooks, so a consumer that already verifies a Svix-style signature needs no change. Consumers written against a bespoke scheme need the small verification snippet, which is about fifteen lines in any language.
Where does the data live?
In the EU — Frankfurt, eu-central-1. That is where it was built and there
is no other region to opt into or pay for. See security.
What happens when a destination is down for hours?
Attempts continue on the retry schedule for about a day. When the schedule is spent the event moves to the dead-letter queue, where it is kept rather than dropped. If a destination fails repeatedly it is disabled automatically and an operational event is published, so you hear about it from your own pipeline. When the destination is fixed, one call resumes it and replays everything that died while it was down.
Is there a free tier?
Yes — see pricing. Signing up takes an email and a password and gives you a live project and a test project.