DEV Community: Angel Hadjiev

Cloudflare's Precursor

Angel Hadjiev — Wed, 15 Jul 2026 13:54:52 +0000

Cloudflare just shipped Precursor, and it effectively kills the oldest trick in web scraping.

It stops judging just the landing request and starts scoring the whole session behaviourally like mouse arcs, keystroke timing, human hand tremors.

The bot score now follows the session. Refreshing, rotating identity, and starting over doesn't reset a thing.

Proxy rotation and header fuzzing were built for a world where the unit of detection was a single request. Whereas now, the defenders are looking at 5-minute behavioural coherence.

The real question isn't whether detection evolves. It's whether your stack is still thinking in requests.

Not being charged for 403s

Angel Hadjiev — Mon, 06 Jul 2026 13:25:49 +0000

Starting off with a full disclosure: I’m not an engineer. Together with my friend - Chapa - we run FourA, a data harvesting infrastructure via a single API. This is a founder’s post; if you wanted a deep dive into code — ping the one, wearing the CTO hat ;]. I ramble on about a pricing bottleneck developers kept complaining to me about, so I wanted to share how we dealt with it.

The thing that bugged us
Almost every scraping and data API bills you per request. You send a request, you pay for it. What actually comes back doesn't seem to matter to the invoice.

That means you pay for the 403 Forbidden. You pay for the Cloudflare challenge page. You pay for the empty body when a target site quietly serves you absolutely nothing. You even pay for the proxy that echoes your own request back as a fake response. Okay, maybe you're just the dev guy and the CDO/CTO pushes the invoice to the CFO, but that's beyond the point.

At low volumes, you don't really notice. At scale, a massive chunk of your bill is just dead weight—money spent on requests that yielded zero data. Ironically, the harder a target site fights back, the more you end up paying the scraping vendor to get blocked. The pricing model literally rewards the vendor when the product fails you.

That felt completely backwards to us. So we decided to change it: you should only pay when you get what you actually asked for. A failed request shouldn't be your financial problem.

Why "just don't bill failures" is a trap
It sounds incredibly simple on a landing page; as a slogan. In production, it’s a nightmare because "success" is highly subjective.

The naive assumption is that success equals an HTTP 200 OK. It doesn't.
Plenty of scraping pipelines legitimately need to record a 404 or 410 to know a product or page is gone.
Some APIs return a 202 or a redirect that contains the actual data you want.

Conversely, plenty of anti-bot walls will happily return a 200 OK status code while serving you a page that just says "Please prove you are human." Technically it's a success; actually, it's garbage.

If we just threw a naive status == 200 ? bill : don't_bill rule into our system, we’d penalise people who need non-200 responses, while still charging users for 200-coded junk.

Our fix: We shifted the definition of success to the user. Now, you send validation rules right along with your request—the status codes you accept, strings that must be present in the HTML, etc. If the response matches your criteria, it’s a success and it bills. If it doesn’t, it’s a failure and it’s free.

Now, a 404 you asked for counts, and a 200 CAPTCHA wall you didn't ask for doesn't. You draw the line, and the bill follows it.

As the non-technical person in the room, I walked away with two main takeaways:

The honest version of a feature is always the hardest one to build. "We don't charge for failures" is a great hook. But making it true meant building a validation engine so customers could define failure themselves. It’s way more complex than a clean marketing slogan, but the simple version would have been an accidental lie for half our users.
Stop guessing, start looking at the logs. Instead of guessing what developers wanted, we shipped the validation feature, looked at our actual internal billing feeds, and iterated based on how data was flowing. (Spoiler: our first version missed a ton of edge cases, which is the part nobody puts on a launch page).

Would love to engage the audience, that can speak from experience. If you run data pipelines at scale: how much of your current scraping bill is spent on responses your parsers just throw away?

Our scraping API is free for everyone through July (no card, no catch - rate limits apply)

Angel Hadjiev — Sat, 04 Jul 2026 12:42:21 +0000

Today America turns 250. We're a two-person web-scraping infrastructure company from the EU called 4A — and with a name like that, the promo wrote itself:

The FourA API is free for everyone through July 31. Sign up, grab an API key, use it. No card, no invoice, nothing to cancel in August.

What it is

One API call, any website: smart proxy rotation, anti-bot/TLS handling (curl-impersonate under the hood), and full browser rendering when a page needs JavaScript. Normally credits only burn on successful requests — failed fetches cost nothing. This month they don't burn at all.

The catch, stated plainly

Rate limits and concurrency caps stay on — unlimited credits, not unlimited parallelism. That's the whole catch.

Why free

We'd rather spend July's marketing budget on your bandwidth than on ads. If the API earns a place in your stack, paid plans exist when the month's over; if not, you got a month of free scraping and we got feedback.

Get a key (~2 min)

Happy 4th to our American friends! Questions about targets, anti-bot, or scale — ask in the comments or directly here: support@foura.ai