One Key, One Bill, One Shape: The Accidental Superpower of Passthru Endpoints

In 2025, enterprises spent $12.5 billion on foundation model APIs — part of $37 billion in total enterprise AI spend, up from $1.7 billion just two years earlier, according to Menlo Ventures' State of Generative AI in the Enterprise. Tripling in a year. The fastest-scaling software category on record.

Now ask the awkward question: how did all that money get spent?

Not through procurement. Not through master service agreements negotiated over six weeks. It got spent because every major model provider converged, without ever agreeing to, on the same purchase pattern: create an account, generate a key, fund a balance, pay per call, read your usage on one dashboard. No contract. No minimum. No sales call. A developer with a credit card is in production in four minutes, and finance sees the bill later.

Menlo's own read of the market makes the mechanism explicit — in AI, product-led motions convert enterprise buyers far faster than traditional SaaS, because real usage proves value before any formal contracting process starts. Adoption ran ahead of procurement. That is not a footnote to the $12.5 billion figure. It is the explanation for it.

Here's the part that should bother anyone selling data: that standard exists for intelligence and does not exist for information. If you want to buy a model's output, there is one well-understood way to do it and it works with every vendor. If you want to buy a weather feed, a firmographic lookup, a search result, or an odds archive, you are back in 2010 — five vendors, five contracts, five pricing schemes, five auth mechanisms, five invoices.

We didn't set out to fix that. We set out to let sellers list an API they already had. But that is what Passthru Endpoints turned out to be.

Ask an engineer who has assembled a pipeline from third-party data sources what the painful part was, and almost nobody says "writing the HTTP client."

Here is what actually happens when a team sources from five providers.

Five procurement cycles. Five vendor forms, five security reviews, five DPAs, five sets of legal redlines — all before a single request is made.

Five pricing models that don't rhyme. One charges per call. One per row returned. One sells seats. One wants an annual commitment with an overage rate. One quotes a number after a call with sales. There is no arithmetic that puts these on a shared axis, which means no way to compare them and no way to forecast what a workload costs before you are committed to it.

Five auth schemes. Bearer token, key-in-query-param, HMAC-signed request, OAuth client credentials with a short-lived token. Each needs its own secret storage, rotation policy, and failure handling.

Five response shapes. Nested differently, paginated differently, with different null conventions, different error envelopes, and different opinions about whether an empty result is a 200 or a 404. Each needs a normalizer, and each normalizer is something your team maintains forever.

Five invoices and five usage dashboards. Nobody can answer "what did we spend on external data last month" without opening five browser tabs.

This is not engineering difficulty. It is transaction friction — and unlike engineering difficulty, it doesn't amortize. The sixth provider is not 20% more work than five. It is another full lap around a track you have already run five times.

There is a quieter cost, and it is the one that actually shapes decisions: you cannot evaluate a provider without first committing to them. When the entry ticket is a signed agreement and a five-figure annual floor, trying a vendor and discovering their coverage is thin in your geography is an expensive experiment. So teams stop experimenting. They use the vendor they already have paper with, or the one a competitor mentioned at a conference, and they live with it.

That is the real damage. Transaction friction doesn't just tax the purchase — it quietly removes the option of shopping around.

For scale: Postman's 2025 State of the API report found that 69% of developers spend more than ten hours a week on API-related work. Multiply that across a data-dependent team and the integration surface stops being a line item and becomes a headcount decision.

Passthru collapses that mess into one pattern — not by asking providers to change anything about how they run their business, but by absorbing the translation on the platform.

Four things get standardized, and each erases a category of friction.

One access pattern. Every Passthru endpoint is reached the same way, with the same Spartera credentials, over the same request contract. The provider's upstream auth — bearer, HMAC, OAuth, key-in-URL, whatever it is — lives in managed secret storage on our side and never becomes the buyer's problem. Adding a sixth provider is a schema, not an integration project.

One purchase pattern. No contract, no minimum, no sales call. A buyer with a credit balance can pull from any Passthru endpoint the moment they find it. Evaluation costs one pull instead of one procurement cycle — which is exactly the mechanism that moved $12.5 billion through model APIs.

One shape. Passthru endpoints declare their schema explicitly: typed input fields the buyer fills, typed output fields they receive. Buyers see the fields before they buy and get exactly those fields after. No normalizer to write, no surprise nesting, no bespoke error envelope. Two providers covering the same domain return comparable structures.

One accounting. One balance, one bill, one usage record across every provider on the platform. "What did we spend on external data last month, and on what" becomes a single query. And because billing is metered per pull, spend tracks actual usage instead of tracking a guess made at contract-signing time about how much you would use.

Here is our stance, plainly: the industry has spent fifteen years standardizing how APIs are called — REST, OpenAPI, JSON Schema, gRPC, and now MCP. It has spent approximately zero years standardizing how APIs are bought. The calling problem is solved. The buying problem is exactly as broken as it was in 2010. Passthru is a standardization layer for the half nobody standardized.

Everything above is a story about making human buyers faster. There is a version of it that is considerably bigger.

An AI agent cannot execute an MSA. It cannot sit through a security review, negotiate an annual floor, or take a call with an account executive. Every piece of transaction friction described above is not a slowdown for an agent — it is a hard wall. The agent simply cannot buy.

The API industry has noticed the gap without quite naming it. Postman's 2025 survey found that while 89% of developers now use AI, only 24% design their APIs for AI agents at all — meaning three quarters of new API surface is still being built on the assumption that a human is on the other end. That assumption fails hardest at the commercial layer, not the technical one. You can hand an agent a perfect OpenAPI spec and it still cannot get access, because access requires a signature.

This is why "your AI agents can't answer real business questions" is not only a plumbing problem. Even with perfect plumbing, the commerce underneath is built entirely around human negotiation. An agent that identifies precisely the right data source is still stuck at the checkout.

A standardized purchase pattern is what removes the wall. One credential, one balance, one metered unit, one machine-readable schema — that is a transaction an agent can complete autonomously at the moment it discovers it needs the data. Passthru was not designed as agent infrastructure. It turns out to be exactly that, and it is the commercial substrate underneath SparteraConnect and the discovery layer we are building on top of it.

"For AI to buy data, data has to be purchasable, not licensable. Those are different words, and the gap between them is where most of the AI data economy is currently stuck. We shipped Passthru as a listing feature. Watching the second seller connect one, it was obvious we had actually shipped a checkout counter." — Tony DiLoreto, Founder & CEO, Spartera

The obvious objection is that standardizing the buy side must mean flattening the sell side — forcing every provider onto one pricing model, one packaging, one set of terms.

It doesn't, and that constraint is what makes the whole thing work.

A seller keeps their upstream business model entirely intact: their own infrastructure, their own rate limits, their own direct enterprise contracts, their own pricing for those contracts. Spartera is not a replacement channel. It is an additional one, and it reaches the buyers the enterprise motion cannot economically serve — the analyst who needs 400 pulls, the startup evaluating three vendors before picking one, the developer prototyping over a weekend, and increasingly the agent that needs one lookup at 3 a.m.

What the seller sets on Spartera is a per-pull price. That single number is what the platform translates into a uniform buyer experience. Stay as complicated as you like upstream; buyers see one number downstream.

The translation is the product. It is the same trick a currency exchange runs: every participant keeps their own currency, and the exchange makes them mutually intelligible.

Worth noting that sellers are already leaning this direction on their own. Postman's 2024 report found 62% of respondents working with APIs that generate income — the API-as-a-product model is no longer novel. What is missing is not the will to monetize. It is the rails.

There is a consequence of "one shape" that deserves its own section, because it changes the market and not just the workflow.

When two providers in the same domain are both listed as Passthru endpoints, a buyer can compare them for the first time. Same request pattern, same output typing, same per-pull unit, same access path. Run both, compare coverage and freshness and price against your actual queries — not against a vendor's benchmark deck — and pick.

Today that comparison is effectively impossible. Two search providers, two weather APIs, two firmographic vendors: one prices per call and one per record, one requires an annual commitment and one doesn't, and the only way to see either one's real output quality is to sign with them first. Buyers don't choose the best provider. They choose the one they could evaluate — usually the one they had already signed.

Price discovery requires comparable units. Passthru creates comparable units. That is good for buyers, and — worth saying plainly — it is good for the providers who are actually better, who currently lose on procurement inertia rather than on merit.

Concretely, listing a Passthru endpoint is three steps.

1. Connect. Register the upstream API as a connection with a passthrough request format. Credentials go to managed secret storage; they never touch the buyer.

2. Define the shape. Declare the request template and the fields. Each field carries a role: input for parameters — buyer-supplied, or seller-fixed and hidden, like a region code you always want pinned — and output for the typed response fields buyers receive. Simple mode auto-generates a flat JSON body from your fields; Advanced mode takes a hand-written template with placeholder slots when the upstream expects a nested shape.

3. Price it and publish. Set a per-pull price. The endpoint lists next to warehouse-backed endpoints with the same discovery, the same purchase flow, the same delivery, and the same 80/20 payout — 80% of every sale to the seller.

Notice what is absent: no data migration, no ETL, no schema modeling, no billing integration, no contract template, no invoicing, no dunning, no usage dashboard to build. The provider brought an API. The platform brought everything that turns an API into a business.

This is also the shape live data took on Spartera in the first place. Our live feed capability began as a request from TxODDS, who wanted odds data sold by the slice rather than by the bulk contract. Passthru generalizes that request to any provider with an API and a price.

Standards rarely arrive by design. Nobody sat down to invent the shipping container as an abstraction for global trade; someone built a box that fits a truck, a ship, and a train, and the abstraction is what the box turned out to be once enough people used it. The value is not in any single box. It is that every port handles every box the same way.

The model API market got its container by accident, through convergence, and grew from $1.7 billion to $37 billion in two years partly because of it. The data API market never converged. Every provider built a bespoke way to sell access; every buyer built a bespoke way to purchase it; both sides have been paying for the absence of a standard, and neither can create one alone. That is precisely the kind of coordination problem a marketplace exists to solve.

One key. One bill. One shape. For any API.

Explore Endpoints →

Browse the marketplace →

List your API as a Passthru endpoint →

Talk to our team →

Spartera is data commerce infrastructure connecting proprietary data sellers to AI companies and analytics buyers. Sellers list warehouse tables, existing APIs, and analytics as purchasable, metered endpoints; buyers and AI agents access every one of them through a single key, a single balance, and a single schema. We handle the pipelines, engineering, payments, and relationships — so neither side has to.