An agent can now call 800 paid endpoints with one key. It still has one counterparty

Published September 4, 2026 · Last reviewed September 5, 2026

On September 2, 2026, Coinbase Developer posted that Orthogonal had grown to more than 700 pay-per-request API endpoints from more than 50 providers, each callable and payable without a separate subscription or signup.¹ Orthogonal’s own site put the figure higher, at 800+ endpoints from 50+ verified providers, reachable through a single integration.²

Read the post carefully and it is not really about payments. Orthogonal’s own copy is three verbs in order, discover, call, and pay, and x402 only settles the third one.² The first two are the expensive part: finding a service that exists and getting a usable answer back from it. That is the interesting claim, because it names the layer everybody in agent commerce keeps pointing at.

What it also does, quietly, is change the shape of the transaction. An agent that calls 800 endpoints through one account, one balance, and one request shape is not dealing with fifty providers. It is dealing with one. That is a sensible engineering trade and a real narrowing of what the agent knows about who is on the other end, and the two facts sit together rather than cancelling out.

What Coinbase Developer actually spotlighted

The underlying company is not new. Orthogonal is a San Francisco startup that raised a $4.3M seed round announced on June 25, 2026, led by Pantera Capital with Y Combinator, Pioneer Fund, Decasonic, Blast, Outbound and Surreal participating.³ The pitch at the raise was already the one in the September post: give agents a way to discover the services they need in the moment, orchestrate them, and pay for them instantly. At that point the catalogue held more than 35 APIs, naming Apollo, People Data Labs, Coresignal, Olostep and Linkup among them.³

Two numbers are worth keeping apart. Providers went from roughly 35 named APIs in late June to 50+ about ten weeks later, which is real growth at a normal pace. Endpoints went to 700+ or 800+ depending on whose count you read, but an endpoint is not a provider, and one API can expose dozens. The endpoint figure measures surface area, not how many independent parties the catalogue has recruited. Both numbers are first-party: Coinbase Developer is relaying a partner’s claim, and Orthogonal is describing its own product.

The mechanics are the part worth writing down. A calling agent integrates once, through an SDK, an MCP server, a REST API, or a CLI, and pays per call with platform credits, x402, or Stripe’s Machine Payments Protocol.² Provider testing, monitoring and uptime tracking are performed by Orthogonal’s team rather than by the calling agent. The categories on offer are the unglamorous middle of go-to-market work: contact enrichment, signal discovery, lead generation, scraping, datasets, model calls.

None of that requires the calling agent to know anything about the fifty providers. That is the product. It is worth being precise that this is a feature rather than an oversight, because the argument that follows is not that Orthogonal built the wrong thing.

Aggregation is winning, and the reason is boring

The promise attached to x402 from the start was disintermediation. An HTTP-native payment protocol, governed since April 2, 2026 by the Linux Foundation x402 Foundation, lets a server answer a request with a price and a client pay it in the same exchange, no account, no contract, no prior relationship.⁴ In principle that means any agent can transact with any service it can address. In principle it removes the middle.

What is actually scaling is the middle. Not because the protocol failed, but because payment was never the expensive part of calling a stranger’s API. The expensive parts are finding out the service exists, reading its documentation, learning its request shape, discovering that its uptime is poor after you have shipped, and doing all of that fifty times. An aggregator collapses fifty integration projects into one. Charging per call on top of that is a small tax against a large saving.

This is a familiar arc. Payment rails lower the cost of a transaction, and the market then reorganises around whatever cost is left standing. Card networks made paying anyone easy and produced payment processors. Open banking APIs produced aggregators. Model APIs became commoditised and produced routers. In each case the intermediary earned its position by absorbing integration and quality work that nobody downstream wanted to repeat, and in each case the buyer ended up with one relationship where the architecture diagram showed many.

The protocol’s own governance has already absorbed the pattern. When the Linux Foundation announced the x402 Foundation’s operational launch on July 14, 2026, the roster ran to forty organisations across three membership tiers, and Orthogonal was on it as a General member, with Coinbase, Circle, Google, Stripe, Visa and Mastercard among the Premier tier.⁴ An aggregator holding a seat in the governance of the protocol it aggregates over is not a contradiction. It is what the arc above predicts. Coinbase sits in the same position from the other side: it launched Agentic.Market, its own browsable marketplace of x402 services, on April 20, 2026, five months before spotlighting somebody else’s.⁵

So the honest read on the Coinbase Developer post is not that x402 is being subverted. It is that x402 works well enough to make the layer above it the interesting business, exactly as Orthogonal says. The question that follows is what that layer knows, and what it does not, about the parties it sits between.

One account, one balance, and the counterparty question

Take the arrangement literally. A buying agent holds one account and one balance. It sends a request in one shape. Money leaves that balance. A result comes back. Somewhere behind the wall, one of fifty-odd providers did the work and got paid, and the buying agent’s code never had to name which one or agree to anything with them.

Ask who the counterparty is in that exchange and the answer is the aggregator, in every sense that matters operationally. It is who holds the balance, who the request was addressed to, who is answerable if the result is wrong, and who the buyer would chase for a refund. We looked at the mirror image of that question, who a seller is dealing with when an agent pays, from the receiving end. The fifty providers are subcontractors to a relationship the buyer has with one party. That is not a criticism; it is what buying through an intermediary means, and buyers choose it deliberately in most markets.

The consequence worth naming is that identity in this arrangement stops at the wall, in both directions. The buying agent does not establish a relationship with the provider that served its request. Just as importantly, the provider does not establish one with the buyer. It sees a call arriving from an aggregator’s infrastructure against an aggregator’s balance. Whatever the buyer is, whoever the buyer represents, and whatever the buyer might be worth as an ongoing customer are all facts the wall absorbs.

For calling a scraping endpoint, nobody should care. Interchangeability is the point of a utility. The care starts where the categories in the catalogue point, and they point somewhere specific: contact enrichment, signal discovery, lead generation. Those are not utilities. Those are the inputs to reaching a person. An agent that assembles a target list through an aggregated catalogue has bought data about humans from parties it cannot name, and the humans in the output never entered any of these relationships at all.

That is the seam. Aggregation is a clean answer to integration cost and a poor substitute for knowing who you are dealing with, and the second problem only becomes visible once the first one is solved well enough for volume to arrive.

Verified provider is a quality claim, not a portable identity

Orthogonal describes its providers as verified, and says its team tests providers and tracks monitoring and uptime.² That is a genuinely useful thing to buy. Somebody checked that the endpoint returns what it claims and stays up, and the buyer did not have to. Treat it as what it is, though, and not as something else.

Vendor verification is a private quality judgement by one gatekeeper about services in its own catalogue. It answers whether this endpoint works. It does not travel: a provider’s standing inside Orthogonal is not readable by any party outside Orthogonal, cannot be presented elsewhere, and disappears if the provider leaves. It is also not about the provider as a party. It is about the endpoint as a product. Nothing in an uptime record says who owns the company, whether they can be held to anything after the call, or whether they exist as a legal entity that can be sued.

This is precisely where the rest of the stack has been trying to get to, and it is worth being fair about how far along that work is. ERC-8004 put Identity, Reputation and Validation registries on Ethereum mainnet on January 29, 2026, which is a serious attempt to make an agent’s standing portable rather than captive to one platform.⁶ A2A Agent Cards published at /.well-known/agent-card.json let a service describe itself in a form any agent can read, on the current v1.0.x line.⁷ Both are real, both are early, and neither is what a curated catalogue provides. Portable reputation and a private QA pass are different objects that happen to answer adjacent questions, and the harder half is that standing does not travel between networks by default.

We covered a nearby version of this argument when Circle described the move from a curated catalogue to an open agent index, and named trusted discovery as still missing. The Orthogonal signal is the same market pulling the other way. Circle’s paper argues the destination is an open index with competing rankers; the growth in the field right now is in convenient walls. Both can be true. Aggregation is what buyers pick while the open version is still a direction paper.

Buying a service is not meeting a party

There are two different things an agent can go looking for, and the vocabulary of agent commerce runs them together under one word.

The first is a callable service. The agent wants a capability, priced, available now, interchangeable with any other implementation that returns the same thing. It does not want a relationship. It wants the cheapest reliable endpoint, and if a better one appears next week it should switch without ceremony. Catalogues are the right architecture for this, aggregation is the right commercial form, and per-request payment is the right rail. This problem is close to solved, and the Coinbase Developer post is evidence of how close.

The second is a party. Somebody an agent’s human might sell to, hire, partner with or be introduced to. Here interchangeability is meaningless. It matters exactly who they are, whether the name resolves to a real person or company, whether their side is willing to be contacted, and whether the introduction can be handed to a human at the end without either side feeling ambushed. No amount of endpoint availability answers any of that, because those are not properties of an endpoint.

The reason to keep them apart is that solving the first raises the pressure on the second. Cheap, instant, unattended access to contact enrichment and lead generation across fifty providers means more outbound, generated faster, by agents that never spoke to the person on the receiving end. The catalogue layer has no place to record that a person agreed to be reached, because a catalogue is a list of things you can call, and a human is not one of them. Registration is published unilaterally by the party who wants to be found. Consent is held by the party who might be contacted. Those are different facts, stored by different people, and the second one has no home anywhere in the payments or discovery stack.

The obvious objection is that regulators have started on this. They have started next door. The EU AI Act’s Article 50 transparency obligations have applied since 2 August 2026, and the Commission’s final guidelines, adopted 20 July 2026, require an agent that interacts with a person to disclose that it is AI, clearly, at the latest at first interaction.⁸ That is a real duty with real penalties, and we read the guidelines in full separately. It governs what an agent must say once it has arrived. It says nothing about whether the person wanted it to arrive. The identity work has the same shape: Web Bot Auth lets a site verify which agent is knocking, which is identity pointed inbound, checked by a server that can already see the request.⁹ Outbound contact into a person’s inbox has no equivalent surface, and a catalogue does not build one.

That is the gap this signal makes larger rather than smaller, which is the honest thing to say about a layer that is otherwise working well.

How this connects to Tobira

Tobira works on the second problem, and it is deliberately not in the business of the first. A Tobira @handle is a human-readable address for an agent that represents a named person or company, published on a network rather than inside one vendor’s catalogue, so a counterparty can find it, talk to it, and learn who stands behind it. The part that a catalogue structurally cannot hold is the one that matters most as call volume rises: contact details are exchanged only after both sides agree, which makes an introduction something the receiving party opted into rather than something the sending party bought access to. Per Tobira’s founder update, June 2026, the network carried 648 agents, including 102 business agents. That sits beside an aggregated service catalogue rather than competing with it, and an agent can perfectly well pay for endpoints over x402 through an aggregator and separately hold a @handle for the introductions those endpoints eventually point at. If you want the longer version of the distinction, it is the same argument as the consent layer for the agentic web.

What to remember

What the aggregated catalogue settles: whether a capability exists and can be found without a procurement cycle; what it costs, per call, before the call is made; whether it works, because somebody tested it and watches its uptime; and how to pay for it, in credits, over x402, or over Stripe’s Machine Payments Protocol, without an account per provider. Fifty integration projects become one. That is a real saving and the reason the numbers in the Coinbase Developer post are going up.

What it leaves open, the moment the output stops being data and starts being a person: who served the request, since the aggregator is the counterparty of record; whether a provider’s standing means anything outside this catalogue, since verification is one gatekeeper’s private judgement about its own inventory; and whether the human at the end of an enriched contact record agreed to be reached, which is a fact that lives with them and is not for sale in any catalogue.

Watch the numbers rather than the headline. Providers moved from around 35 named APIs in late June to 50+ by early September, which is the figure that tracks how many independent parties are in the catalogue. Endpoint counts, whether 700+ or 800+, measure surface area and will grow faster for reasons that have nothing to do with counterparty diversity.

Somewhere between 700 and 800, depending on which page you read, an aggregator is still counting endpoints. Nobody is counting the people at the end of the enriched contact records.

FAQ

What did Coinbase Developer announce about Orthogonal?

Coinbase Developer posted on September 2, 2026 that Orthogonal had expanded to more than 700 pay-per-request API endpoints from more than 50 providers, covering contact enrichment, signal discovery, lead generation and similar agent tasks, with no separate setup or subscription per provider. Orthogonal’s own site put the figure at 800+ endpoints from 50+ verified providers at the same time. This was a partner spotlight rather than a Coinbase product launch, and both numbers are first-party claims by the companies making them.

Is an aggregated API catalogue the same as open agent discovery?

No, and in one respect it is the opposite. Open discovery means any agent can find and evaluate any service without a gatekeeper choosing the shortlist. An aggregated catalogue means a gatekeeper has chosen the shortlist, tested it, and put it behind one account, which is why it is convenient. Both models are growing at once, and the aggregated one is currently growing faster because integration cost, rather than payment, was the binding constraint on calling a stranger’s API.

Who is the counterparty when an agent pays through an aggregator?

The aggregator, for every practical purpose. It holds the balance, receives the request, and is who the buyer would pursue if the result is wrong. The provider that performed the work is a subcontractor to that relationship, and it sees a call from the aggregator’s infrastructure rather than from the buying agent. Identity stops at that wall in both directions, which is fine for a utility endpoint and consequential when the output is information about a person.

Does provider verification give an agent portable reputation?

No. Verification of this kind is a quality judgement made by one platform about services in its own catalogue: the endpoint returns what it claims and its uptime is monitored. It is not readable outside that platform, cannot be presented elsewhere, and does not survive the provider leaving. Portable agent reputation is what ERC-8004’s Identity, Reputation and Validation registries are attempting, on Ethereum mainnet since January 29, 2026, and that is early infrastructure rather than a substitute for a working catalogue.

Where does consent fit into any of this?

Nowhere in the current stack, which is the point. Discovery tells an agent that a party can be found. Payment authorisation caps what the agent may spend. Neither records that the human on the receiving end agreed to be contacted, because registration is published unilaterally by whoever wants to be found, while consent is held by whoever might be reached. As catalogues make outbound cheaper and faster, the volume of contact goes up and the missing consent boundary becomes more consequential, not less.

Sources

• Coinbase Developer, post on X, September 2, 2026. https://x.com/CoinbaseDev/status/2095278916730597562
• Orthogonal, product site. https://www.orthogonal.com/
• Orthogonal announcement quoted by Coinbase Developer. https://x.com/chrisspickett/status/2095219421669118003
• “Orthogonal Raises $4.3M Seed for AI Agent Service Discovery, Orchestration, and Payments Across the Internet,” PR Newswire, June 25, 2026. https://www.prnewswire.com/news-releases/orthogonal-raises-4-3m-seed-for-ai-agent-service-discovery-orchestration-and-payments-across-the-internet-302806969.html
• Linux Foundation, x402 Foundation announcement, April 2, 2026, MCP Dev Summit North America.
• Linux Foundation, “Linux Foundation Announces Operational Launch of x402 Foundation,” July 14, 2026. https://www.linuxfoundation.org/press/linux-foundation-announces-operational-launch-of-x402-foundation-to-standardize-internet-native-payments-for-ai-agents-and-applications
• Coinbase Developer Platform, “Introducing Agentic.Market,” April 20, 2026. https://www.coinbase.com/developer-platform/discover/launches/agentic-market
• European Commission, transparency obligations under Article 50 of the AI Act. https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act
• Cloudflare, Web Bot Auth. https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/
• Coinbase Developer Documentation, x402 overview. https://docs.cdp.coinbase.com/x402/welcome
• ERC-8004, Trustless Agents. https://eips.ethereum.org/EIPS/eip-8004
• A2A protocol releases. https://github.com/a2aproject/A2A/releases
• Tobira founder update, June 2026, for the network figures cited in the Tobira section.