Bots passed humans on the web this year. Most software still isn't built for the new majority user

Cloudflare’s network data crossed a line in 2026 that’s worth sitting with: automated requests now account for roughly 57.5% of HTTP traffic across its network, edging out humans for the first time the company has recorded it. Most of that is AI crawlers and training bots, not autonomous agents acting on a person’s behalf — but the direction is the same one showing up in a separate, more specific number from Postman’s developer survey: only about 24% of developers say they actively design their APIs with AI agents as a consumer in mind. Sixty percent are still designing primarily for humans clicking through a UI.

That gap — a majority-automated web, and a minority of teams building for it — is the real 2026 story, and it’s a bigger deal for a vendor’s product strategy than “add an API” makes it sound.

The user changed before the interface did

For most of software’s history, “the user” meant a person with eyes, a mouse, and patience for a UI. An AI agent calling your product on someone’s behalf is not that user. It doesn’t read a dashboard, doesn’t infer meaning from layout or color, doesn’t know that the “delete” button moved to a different menu last release. It calls an endpoint, gets a response, and has to decide what to do next based entirely on what that response actually says — structurally, not visually.

That’s a different bar than most software was built to. A UI can paper over an inconsistent backend with good design: a human notices the “estimated delivery date” field is sometimes a string and sometimes null and just squints at it. An agent parsing that same field programmatically either crashes, silently mishandles it, or — worse — proceeds confidently on a bad assumption. Software that was UI-first for a decade can carry years of that kind of inconsistency without anyone noticing, because a human papered over it every time. An agent doesn’t paper over anything.

What “a real API” means once an agent is the caller

“We have an API” stopped being a differentiator years ago — the more specific question a 2026 buyer, or a 2026 agent developer, should be asking is whether that API was actually built to be called by something other than your own frontend. A few concrete properties separate the two:

• Typed, predictable responses. Not “usually returns this shape.” An agent (or the code wrapping it) needs to know, ahead of time, exactly what fields exist and what type they are, so it can act on a response without a human eyeballing it first.
• Errors that are data, not prose. “Something went wrong, please try again” is fine for a human staring at a toast notification. It’s useless to an agent deciding whether to retry, back off, or give up — that decision needs a machine-readable error code and category, not a sentence meant for a person.
• Idempotency on anything that changes state. A human who double-clicks “send” notices the duplicate and complains. An agent that retries a timed-out request has no such instinct — without an idempotency mechanism, a flaky connection can turn one intended action into several, silently.
• Consistent pagination and naming across every resource. A human adapts to inconsistency between screens without thinking about it. Code calling ten different endpoints with ten different pagination styles has to write ten different pagination handlers, which is exactly the kind of friction that makes an agent-facing integration expensive to build and brittle to maintain.

None of these are new engineering ideas — they’re standard API design practice that’s been optional for a decade because the primary caller tolerated their absence. What changed in 2026 isn’t the idea, it’s the caller: when a meaningful share of your product’s traffic is a program deciding what to do next based on your response, “usually works, a human will notice if not” stops being an acceptable design philosophy.

Why this specifically favors vendors who already had the discipline

The practical consequence of the Postman gap — 24% building for agents against 60% still building for humans only — is that a UI-only or UI-first-with-a-thin-API product has real, current-year work to do before an agent can reliably automate it, while a product that already treats its API as the primary surface (the dashboard is a client of it, not the other way around) has comparatively little to change. The typed responses, the predictable errors, and the idempotency were already there for the human developers calling it directly; an agent calling the same surface inherits all of it for free. The receipts for what that actually looks like in practice — one contract, typed errors, cursor pagination, consistent field names across every operation — are the same properties this post is describing from the agent-traffic angle instead of the developer-experience one.

What to do with this if you’re building right now

If you’re a developer building against someone else’s API in 2026, the Cloudflare and Postman numbers together are a useful filter: before wiring an agent up to a vendor’s product, check whether their API returns typed errors you can branch on, whether state-changing calls accept an idempotency key, and whether the field names and pagination are consistent across the operations you’ll actually use. If the answer is “the UI is great but the API feels like an afterthought,” that’s not a hypothetical problem anymore — it’s the exact gap a majority-automated web is about to make expensive. The Norbelys API was built to pass that check from day one; the developer portal has the OpenAPI spec if you want to verify it yourself rather than take the claim on faith.