The story
Outbound calls are a security boundary. We treat them like one.
Most systems can reach anything they can resolve. That is not a feature — it is an unguarded door with a green light above it. Backfire started from one conviction: the moment your code calls a URL you did not write, someone should be able to say who allowed it, what it touched, and what it cost.
Why this exists
Security is usually a policy document. Here it is the path the request takes.
Every modern application reaches outward: a payment provider, a model endpoint, a customer’s own webhook, a URL a user pasted into a form. Those calls are written in dozens of files, authenticated with secrets scattered across environments, and rarely reviewed as one surface. When something goes wrong, the honest answer is usually that nobody can reconstruct the path.
Backfire collapses that surface into one authenticated endpoint. Your application sends a target, a method and a body; the relay checks the key, refuses anything that points inward, makes exactly one call, and hands back a predictable JSON envelope. One place to revoke. One place to see the budget. One place to read the history.
That is the whole product, and it is deliberate. A relay that also orchestrates would be a platform you have to trust with your logic. Backfire only takes responsibility for the boundary — so it can be small enough to be accountable for it.
Control, made concrete
A key per app, never a shared secret
Every call carries a bearer key you minted, stored only as a hash. Revoking it takes effect on the very next request — no deployment, no cache to wait out.
Blocked by default
Private, loopback, link-local and cloud-metadata addresses are refused before a socket opens. Ambiguous DNS answers fail closed, and redirects are never followed.
Nothing to reconstruct afterwards
Target, headers, request body and response are purged the moment the trip completes. Your code keeps the data; the relay keeps only the count.
Isolation the database enforces
Each account can read only its own keys, balance and activity log. The rule lives in the database, not in application code — the ledger is reachable only from server-side code and every query is scoped to your account — so a mistake in a query cannot cross accounts.
Where this is going
Every outbound call a program makes should be answerable to someone.
That is the ambition, and it is bigger than one relay. It is a shift in how teams treat egress: from an invisible side effect of writing code to a line item with an owner, a ceiling and a receipt.
- 01
Make outbound access a decision a system records, not an ambient capability it just happens to have.
- 02
Keep the control plane small enough that one person can be accountable for every line of it.
- 03
Publish the limits, the refusals and the price — so nothing about the service is discovered in production.
Who builds it
Gurutva Murdia
Solo creator and operator
Backfire is not a committee product or a funded team. It is designed, built, deployed and supported by one person, who answers the email address below and is accountable for everything the service does.
backfireapi@outlook.comOne operator means one throat to choke — and one person to hear from.
There is no support tier queue, no account manager and no roadmap decided in a room you cannot enter. When you write to support, you are writing to the person who wrote the relay, the blocklist and the ledger. That is a deliberate trade: slower to scale, far quicker to be honest.
The brand follows the same rule. Security and control are not campaign words bolted onto a landing page — they are the reason the product has keys, refusals, limits and a published cooldown instead of a vague promise of safety.