Webhooky Alternative: Hookfire vs Webhooky

Hookfire vs Webhooky

Webhooky takes whatever JSON you send it. Hookfire already knows what 33 providers send, and checks they really sent it.

The difference between these two is the difference between a blank endpoint and a catalogue, and which one is better depends entirely on where your events come from.

Webhooky's shape is an endpoint that accepts what you send it. You point anything at it, you write the title and body with placeholders pulled out of your own payload, and you pick a sound. That is a genuinely good fit when the thing you want alerts about is your own code: a deploy script, a nightly job, a server you wrote the monitor for. Nobody needs to model your payload for you, because you already know it.

Hookfire's shape is the opposite. Thirty-three providers are described in advance: which events exist, what each event's notification should say, where the interesting values live in the body, and how that provider signs its requests, which is the part a generic endpoint structurally cannot do. A generic receiver's defence is a secret in the URL, which proves that whoever posted knew the URL. Hookfire checks Stripe's signature with Stripe's scheme against the raw bytes, so a notification can only come from a payload Stripe actually signed.

One place Webhooky is plainly ahead: sounds. A cash-register noise for a sale is a small feature that people genuinely enjoy, and Hookfire does not send a sound field at all today. What Hookfire has instead is priority: four levels, where critical re-sends every five minutes up to six times until somebody acknowledges it. That answers "wake me up" rather than "which of these buzzes is which", and if the second question is the one you have, that is a real reason to pick the other tool.

Where they differ

The shape of each tool rather than its price list, because that is the part that is still true next quarter.

	Webhooky	Hookfire
What you point at it	Any JSON you can POST, from your own code or from a provider	Any of 33 mapped providers, plus custom sources you define in YAML yourself (Max)
Writing the notification	You write title and body with placeholders from your payload	Written per event and shipped with the source; editable per integration on Max
Proving who sent it	A secret endpoint URL, the usual mechanism for a generic receiver	The provider's own signature scheme, checked against the raw body before anything renders
Sounds	A large library, chosen per notification	None yet; priority is what changes how an alert arrives
Getting somebody's attention	Sound and, as with any push, the notification itself	Four priorities; critical re-sends every five minutes, up to six times, until acknowledged

What arrives already built with a mapped source

A tap that goes somewhere

The alert carries a link back to the thing it is about (the Stripe payment, the GitHub pull request), built from the payload and dropped entirely unless it resolves to a plain http(s) URL.

Quiet hours, snooze and mute

Quiet hours in your own time zone, a snooze that expires by itself, and a mute that covers a whole integration for everyone. None of the three stop the event being recorded; what is suppressed is the interruption.

Filter rules

A condition on the payload decides whether anyone hears about the event at all, which is useful precisely when the source is somebody else's and you cannot edit what it sends.

A full history

Every delivery is recorded with its status, there is a view of just the failures, and any one of them can be replayed by hand against whatever the templates say now.

Choose Webhooky if

Webhooky is a general endpoint you POST to, with notification text you compose from your own payload and a large library of sounds.

What you want alerting on is your own code, not a third party's. A blank endpoint beats a catalogue when you are the one writing the payload.

The sound library matters to you. It is a real feature and Hookfire has nothing to put against it.

You want one endpoint that twenty unrelated scripts can share without any of them being modelled first.

You do not need the signature checked, because you control both ends of the wire.

Choose Hookfire if

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

The events you care about come from providers you do not control and cannot change.

You want the signature verified, not just a secret URL kept quiet.

You would rather adjust a notification that already reads well than write thirty from scratch.

You need the noisy events filtered out before they reach a phone, not after.

Using both

These two are not mutually exclusive, and the split is obvious once you say it out loud: the generic endpoint keeps your own scripts, Hookfire takes the providers. Both can run on the same phone and neither knows about the other.

If you would rather consolidate, Max's custom sources close the gap from the Hookfire side. A custom source is a small YAML file naming where the event type sits in the payload and what the title and body should say for each one. After that your own scripts POST to Hookfire exactly as they would to any generic endpoint, and get the same filtering, priorities and history as the built-in sources.

Common questions

Can Hookfire take arbitrary JSON too?

Yes, on Max, through a custom source. You describe the payload once in YAML, saying where the event type lives and what each event should say, and from then on anything that can POST is a source like any other.

Hookfire has no sounds. What actually gets my attention?

Priority. Low, normal, high and critical, set per event and overridable per subscription, with critical re-sending every five minutes for up to half an hour until somebody acknowledges it. It is aimed at the alert you must not sleep through rather than at telling two alerts apart by ear.

Can I change what a built-in notification says?

On Max, per integration and per event. Leave a field alone and it keeps tracking the built-in template, so fixing the body does not mean freezing the title.

What happens during a spike?

An integration can carry an hourly cap. Past it, events are still received, rendered and recorded: they go to the inbox rather than to a phone, and you get one notice that the cap was reached rather than one per event.