Webhook Push Alternative: What Hookfire Actually Does

Hookfire as a Webhook Push alternative

Rather than describe someone else's product secondhand, this page describes ours exactly, every step a webhook goes through.

This page is deliberately one-sided, and it is worth saying why before you read it.

We are not going to characterise another team's product from the outside. Feature lists go stale, roadmaps land, and a comparison table built out of guesses about somebody else is the fastest way to be wrong in public. Their own site is the accurate source for what they do this month.

What we can do precisely is describe Hookfire. So that is what follows: the actual path a webhook takes through it, in order, with nothing in the list that is not in the code. Hold it next to whatever else is on your shortlist and the comparison makes itself.

The short version, if you only want the shape: 33 providers are described in advance, the ones that sign their requests are verified, a filter can drop an event before anyone hears about it, the notification text was written by a person and can be rewritten by you, and where it lands (phone, email, a team channel) is a choice per person rather than a property of the product.

What happens to a webhook inside Hookfire, in order

1. It arrives at a URL that is yours alone

Each integration gets its own inbound token. Nothing else in the system answers on that URL, and pausing an integration stops it dead.

2. The signature is checked

Each provider's own scheme against the raw bytes: Stripe's timestamped HMAC, GitHub's hex digest, Shopify's base64, Svix's, and the rest. A body that fails is refused before anything is rendered. The providers that do not sign at all are marked as such on their own integration page rather than being quietly waved through.

3. Your filter rules run

A rule reads a value out of the body by dot path, such as `data.object.amount` or `commits.0.message`, compares it, and the event is delivered or dropped on the answer. A rule about a value that is not there is false, so an unexpected payload sends nothing rather than sending everything.

4. The notification is rendered

From a template written for that specific event: the amount, the currency and the customer already in the title, and a tap-through link back to the payment or the pull request. On Max you can rewrite any of it per integration.

5. It is routed per person

Each member of the org chooses push, the inbox, or email for each integration. Max adds Slack, Discord and Microsoft Teams as channels for the alerts the whole team should see.

6. Priority decides how hard it knocks

Low, normal, high or critical, with an admin able to override per subscription. Critical re-sends every five minutes, up to six times, until somebody acknowledges it, and it is allowed through snooze and quiet hours, because that is the situation it exists for.

7. Quiet hours, snooze, mute and the hourly cap can hold it back

Each suppresses the interruption, not the record: the event is still in the history and still in the inbox with the reason it did not buzz. A muted integration is the one thing a critical alert does not break through, because muting is a deliberate decision about that source.

8. The delivery is recorded, and can be replayed

Status per person, per channel, a view of just the failures, and a replay button that re-runs one delivery against whatever the templates and subscriptions say now, which is how you check that a fix worked.

9. It can be forwarded on

The verified webhook can go on to your own HTTPS endpoint, signed with a per-destination secret, with the destination re-checked against a fresh DNS lookup right before each request so it cannot be pointed at something internal after the fact.

10. If it stops arriving, you hear about that too

An integration that was delivering and has gone quiet raises its own alert, once, and stops when traffic comes back.

Choose Webhook Push if

Webhook Push is in the same category: a webhook arrives, and your phone tells you about it.

Their app is the one you enjoy using. For a tool that lives on your lock screen this counts for more than a feature row.

A provider you depend on is covered there and is not one of Hookfire's 33. Check the integrations list first, it is the fastest way to settle this.

You have already set it up and it works. Replacing working alerting is rarely the best use of an afternoon.

You want something simpler than the list above. Not every setup needs filters, channels, priorities and forwarding, and paying for them unused is a bad trade.

Choose Hookfire if

33 providers already mapped and verified, turned into notifications a person can act on.

You want to read exactly what happens to a payload before you trust it with your alerts. The list above is that, and every line of it is in the code.

Signature verification per provider is a requirement rather than a nice-to-have.

High volume means the useful feature is the one that stops notifications, not the one that sends them.

The same event needs to reach a phone, an inbox and a team channel, each for different people.

How to settle it in an afternoon

Alerting tools are unusually cheap to evaluate, because no data lives inside them. There is nothing to migrate and nothing to lose, which means the only sensible test is the real one: point the same provider at both and watch a week of actual events arrive twice.

Most providers will happily send the same webhook to two endpoints, so this costs a setting rather than a commitment. Then judge on the things a feature list cannot show you: whether the notification tells you enough to act without opening anything, and whether after five days you are still reading them or already swiping them away. That second one is the whole product, and it is the only test that catches it.

Common questions

Why won't you compare feature by feature?

Because we would have to guess, and a guess about somebody else's product is the one thing on a page like this that a reader can check and catch. Describing our own side exactly is more useful and it stays true.

Which providers are built in?

Thirty-three, spanning payments, billing, ecommerce, developer tools, support and feedback: Stripe, PayPal, Square, Shopify, WooCommerce, GitHub, GitLab, Sentry, Vercel, Zendesk, Intercom and the rest. The integrations page lists every one with its events.

What if two of us want different things from the same integration?

That is the normal case. Delivery is per person: one of you can take push for everything, another only email for failures, and a third nothing at all while still reading the inbox.

Is there an API?

Yes, including the acknowledgement endpoint that stops a critical alert repeating.