Two API sellers declined our invitation to join an agent marketplace. For now, the integration was more work than they could justify.
We had a federation protocol, signed catalogs, and receipts. They already exposed paid API routes. Our proposal gave them something else to maintain before we could show that maintaining it would bring them customers.
On October 30, their replies changed what we built.
The integration looked small from our side
Our project, AIMarket, connects hubs that help agents discover and call services. Our invitation asked sellers to publish discovery information and a signed manifest of their routes and prices. The full federation path also supports signed receipts.
There are good reasons for those requirements. An agent needs to know where an offer came from, what it costs, and what evidence it will keep after a call.
But a manifest is an ongoing commitment. Prices change. Routes change. Someone has to make sure another representation of the service stays correct.
From our side, this was protocol support. From the seller's side, it was another integration to own.
Two refusals, two useful answers
I'm paraphrasing the replies here, rather than quoting private email.
SWARM said that a signed manifest, keeping it current, and signed receipts were real work. It reported no repeat outside buyer for its routes, including the two we were discussing. It wanted to leave those routes as they were, and revisit the conversation if repeat payers appeared.
TensorFeed pointed to the cost of keeping each manifest synchronized with live pricing. It was keeping its list of integrations short, and would reconsider if the federation grew and agents actually routed through it.
These were two conversations, not a survey of the market. They were enough to expose a weakness in our own offer.
We were asking sellers to pay a recurring integration cost against an uncertain future benefit.
That uncertainty was already familiar. Earlier in October, we tried buying a call from 100 x402 sellers. The distinction between working delivery and actual demand was the central finding. Our own test purchases could establish that a route worked; they could not establish that customers wanted it.
Now we were hearing the same problem from the other side of the counter.
We moved the maintenance to the hub
The sellers already published information for x402, a payment flow in which an HTTP 402 Payment Required response tells a caller how to pay for a request.
Could our hub use that existing surface instead of asking for a new one?
We added a separate way to appear in discovery: an observed listing.
With the seller's consent, the hub:
- Reads the seller's existing x402 discovery document.
- Sends a bounded, unpaid request to an agreed route.
- Reads the price, asset, network, and payment recipient from the resulting
402. - Lists what it observed, with a timestamp and an explicit statement that the seller did not sign the listing.
The seller doesn't maintain an AIMarket manifest for this path. A buyer calls the seller's URL and pays the seller directly. The hub is outside that payment path.
This also changes what we can honestly promise.
A signed catalog is a statement from a seller. An observed listing is a statement from us: at this time, this URL returned this payment offer.
It does not prove delivery. It does not prove who operates the service. It does not turn a service into an admitted federation peer.
We keep these listings separate from the federation catalog and from calls routed through the hub. The distinction exists in storage and API behavior, as well as in the wording shown to a buyer.
Even an unpaid request can cost the seller
TensorFeed exposed the next problem before we could offer this as a solution.
Its published discovery document describes a free trial: 100 premium calls per IP in a rolling 24-hour window. An unpaid request could consume that allowance and return a successful answer instead of a 402 price quote.
Our supposedly cheap listing check could spend the seller's trial allowance without obtaining the offer we needed.
We put that listing proposal on hold. The prepared follow-up asks whether there is a way to request a payment quote without consuming the trial. It is a question, not a supported integration.
The implementation stops probing that seller for the rest of the observation cycle when a route answers for free. That prevents a sweep through its remaining routes; a later scheduled cycle can still make another request. The default interval is six hours.
A route that validates required input before quoting can return 400 or 422 to our empty probe instead. That route is not listed either. This approach needs a usable payment challenge; a public discovery document alone is insufficient.
Moving work to our side still requires understanding whose resources our automation consumes.
Less seller work means a narrower claim
We added two boundaries around the observed offer.
First, the hub pins the initial payment recipient. If a later response names a different payTo address, the affected route is withdrawn until the operator reconfirms the recipient with the seller. A legitimate payment-address change needs attention; so does a compromised endpoint.
Second, observations expire. An offer older than twice the configured observation interval drops out of buyer search results. With the default interval, that means twelve hours.
A buyer still needs to check the actual payment challenge. It should refuse a changed recipient or a price higher than the listing showed.
These checks don't make an observation equivalent to seller-signed evidence. They let us offer a smaller, useful claim without quietly borrowing the guarantees of the stronger path.
What we actually shipped
The October 30 rollout record covers six hubs. The feature was deliberately disabled in our simulation realm, which does not issue real payment offers.
On our main hub, we tested the whole path with our own route: record consent, read its discovery document, obtain a 402, list the $0.003 offer with its recipient pinned, find it in search, and delete it again.
That proves the plumbing worked for our test. It is not an outside seller joining, a customer acquisition, or a sale.
At that rollout, the external seller list was empty. We had no recorded consent from either seller for the new path. The follow-up messages were prepared; TensorFeed's offer remained on hold because of the free-trial issue.
A fresh check on October 31 at 10:49 UTC still returned an empty observed-seller list on our main hub. We changed the product. We have not yet established that the change makes it worth joining.
The next measurement is someone else's decision
Their objections changed who does the work. A shorter integration guide would have left the recurring maintenance with the seller.
We still have the stronger federation path for sellers who want its guarantees and routing. We also have a smaller discovery path that can use an existing payment surface, with consent and explicit limits.
Now the questions are concrete: will a seller agree to be listed this way? Can we observe an offer without consuming its free service? Does discovery bring a buyer who comes back?
Another successful deployment cannot answer those questions.
We built the integration. The sellers reminded us that we also have to make it worth maintaining.
Disclosure: I used AI assistance to develop the software and prepare this article. The account above is based on our saved outreach records, implementation, tests, October 30 deployment evidence, and an October 31 check of public discovery documents and our main hub listing. Seller replies are paraphrased; our own probes are identified as tests. The cover illustration was generated with AI; the explanatory diagram was drawn from the implementation.
Top comments (4)
observed vs signed listing is a really honest split. curious if buyers will actually treat them differently or just go with whatever shows the price they want
We don’t know yet whether buyers will treat them differently. The API already keeps observed offers separate from signed catalogs, and we can make that distinction clearer in the buying interface: what was observed, who signed what, and when it was checked. A signature still doesn’t prove delivery. The next question is whether showing that evidence changes a buyer’s choice—we haven’t measured that yet.
That TensorFeed trial detail changes the math. How do you probe a route for a price without spending the seller's free calls?
We don't have a general way yet, and that's why TensorFeed isn't listed.
Today the probe is one unpaid request per route. If a route answers for free, we don't list it and skip that seller's other routes until the next cycle. At the default six-hour interval that caps it at four free calls a day, but those are still calls the seller serves for nothing, so we haven't turned it on for TensorFeed.
Their discovery document already names a price and a payTo for each route. What the probe adds is evidence that the live route asks for that price and pays that address. Without it, we could list the document's figures, labelled as the seller's published price rather than an observation, or not list the route. For now we don't list it.
The clean fix has to come from the seller: a header or a HEAD request that returns the 402 without serving the call or counting it against the trial. That's the question TensorFeed would need to answer.