Backfire compared with ScraperAPI

Which one you actually need

Choose ScraperAPI when the obstacle is the target defending itself. Choose Backfire when the obstacle is that you cannot trust the URL, or cannot prove afterwards what you called.

Side by side

# ScraperAPI shapes the call for you (rendering, retries, geo)
GET https://api.scraperapi.com?api_key=$KEY&url=$TARGET&render=true&country_code=us

# Backfire sends exactly what you composed, and tells you exactly what happened
POST /functions/forward
{ "url": "https://api.partner.example/v1/items", "method": "POST",
  "headers": { "x-tenant": "acme" }, "body": { "page": 2 } }

# Response: same method, same headers, same body — plus the record of it.

Where the other one wins

• Retries hide failures. A relay that retried for you would double-charge trips and make duration_ms meaningless, so Backfire reports the failure and lets your code decide.
• If your job is a scheduled crawl of pages you have rights to, a scraping API with rendering and retry state is the shorter path.
• If the job is "a customer pasted a URL into our product and we must call it safely", no scraping API addresses that. The guard is the feature.
• Neither product decides whether you are allowed to call a target. That is a terms-of-service question, and it is yours.

What Backfire will not do

• One attempt per call: no retry, no failover between exits, no rendering fallback.
• No country selection — the relay uses its own egress, full stop.
• A refused target is not billable, but a call that reaches the network costs a trip even if the upstream errors.
• Backfire will not help you get past a block; it will report the 403 faithfully.

Other comparisons