Can Backfire be my webhook receiver?

No. It is outbound-only: your code asks it to make a request. Receiving needs a public endpoint of your own, or a webhook service in front of one.

Does Backfire retry failed outbound webhooks?

Not for requests you make through the relay — one attempt per trip. Its own account events are queued and retried, because those are Backfire's responsibility, not yours.

Backfire vs Hookdeck

Backfire compared with Hookdeck

Hookdeck is a webhook layer: a stable URL to receive events, a queue in the middle, retries, replay, and an inspector for deliveries. Backfire is a synchronous outbound call — you send a target, body and headers, and you get the response back in the same request.

Which one you actually need

Receiving third-party events, absorbing spikes, replaying failures: Hookdeck. Making one outbound call from your own code with a guard, a key and a record: the relay. Teams that do both often run both.

Direction of concern

Hookdeck: Inbound events, queued and retried
Backfire: Outbound requests, one at a time

Delivery semantics

Hookdeck: At-least-once with retry windows
Backfire: Exactly one attempt, no queue

Replay and inspection

Hookdeck: Core feature
Backfire: No replay; the activity log records what happened

Latency profile

Hookdeck: Asynchronous by design
Backfire: Synchronous — the response comes back now

Signing

Hookdeck: Verifies inbound, signs outbound
Backfire: Signs its own account events; you sign your own payloads

Where it sits

Hookdeck: Between sender and your endpoint
Backfire: Between your code and a third-party target

Billing shape

Hookdeck: Subscription by event volume
Backfire: Prepaid trips, one per completed roundtrip

Dimension	Hookdeck	Backfire
Direction of concern	Inbound events, queued and retried	Outbound requests, one at a time
Delivery semantics	At-least-once with retry windows	Exactly one attempt, no queue
Replay and inspection	Core feature	No replay; the activity log records what happened
Latency profile	Asynchronous by design	Synchronous — the response comes back now
Signing	Verifies inbound, signs outbound	Signs its own account events; you sign your own payloads
Where it sits	Between sender and your endpoint	Between your code and a third-party target
Billing shape	Subscription by event volume	Prepaid trips, one per completed roundtrip

Side by side

hookdeck

// webhook infrastructure: a durable endpoint with retries in front of you
POST https://events.hookdeck.com/e/src_xxx      // sender points here

// relay: one outbound call, answered in this request
const res = await fetch('https://backfireapi.base44.app/functions/forward', {
  method: 'POST',
  headers: { Authorization: `Bearer ${key}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({ url: partnerUrl, method: 'POST', body: event }),
});

Where the other one wins

Backfire does not accept inbound webhooks. It has no public URL for your senders to call, and no queue to replay from.
Backfire does emit its own account events — quota low, denials, key changes — signed with an HMAC secret and retried from a queue. That is delivery for Backfire events, not a general webhook service for your product.
If a partner requires retries with exponential backoff and a dead-letter queue, that is Hookdeck territory. The relay will tell you the first attempt failed and stop.
The two compose: route the outbound call through the relay, consume the partner's callbacks through a webhook layer.

What Backfire will not do

No inbound endpoint, no queue, no replay, no delivery guarantees for your own events.
No retry policy: a failure is reported once and is your decision to repeat.
Synchronous only — a slow target holds your request open until the timeout is reached.
Signing applies to Backfire's own account events, not to arbitrary payloads you send.

Other comparisons

ScrapingBee ScraperAPI Bright Data A public CORS proxy