Backfire compared with calling fetch() directly

When each one wins

Choose a raw fetch() when the target is a fixed, hardcoded host inside a trusted network. Choose Backfire when the URL is influenced by a user, a model or a webhook payload, or when you need per-call evidence.

The same call, side by side

// before: the URL decides where the request goes
const res = await fetch(userUrl);          // redirects followed, no ceiling, no record

// after: the same call, with the key, the guard and the log attached
const envelope = await (await fetch('https://backfireapi.base44.app/functions/forward', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.BACKFIRE_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ url: userUrl, method: 'GET', timeout_ms: 8000 }),
})).json();

if (!envelope.ok) throw new Error(envelope.error.code); // blocked_target, dns_failure, rate_limited
return envelope.body.json ?? envelope.body.text;

Worth knowing

• A raw fetch() inside a private network can legitimately reach internal services. Backfire cannot, and will not try — that restriction is the product.
• The relay cannot know your business rules. An allow-list of hosts your product should call is still your job, and it is the strongest complement to the SSRF guard.

Limits that stay your problem either way

• The relay cannot know which hosts your product should call — an allow-list stays yours to write.
• One extra hop of latency, reported as duration_ms on the upstream leg so you can measure it.
• A request that reaches the network costs a trip even when the upstream answers 500; refusals are free.
• Redirect policy is still a decision you make in code — the relay returns 3xx rather than following it.