Some API sellers now publish a second front door for software: an agent-accessible API storefront at agents.their-domain, where a program can read the catalogue, the prices, the error codes and the identity rules without a signup form. Open the identity document at four of them in one afternoon and you slowly realise you are reading the same page. On 18 September 2026 the auth.md at a market data seller, a sports data seller, a search results seller and an image generation seller were identical apart from the hostnames, the seller's name, one extra card lane at the image seller, and a pay-as-you-go section the search results seller leaves out. Same numbered steps, same keychain commands, same error strings. Buried in step three of all four is the sentence that interests me: an unclaimed credential "expires after a few days and any plans bought with it die with it".
That sentence tells you what the email ceremony in these systems is actually for, and it is not authentication. An anonymous credential registered with one unauthenticated POST already authenticates fine. It holds a secret, it exchanges that secret for short-lived access tokens, and the storefront can tell across a thousand calls that the same holder came back. What the anonymous credential cannot do is survive its own loss. I think that is the real product of the claim step: not a name, but a recovery anchor, a second party who can be asked later whether some prior state belonged to you. Identity here is a durability feature that happens to be spelled like an account.
The account bundled four jobs, and only three of them survive the key going away
An API key and the account behind it always did several things at once. It authenticated the caller. It carried authorisation, in the sense of which plan or scope the caller held. It attached usage to a bill. And, quietly, it made the whole arrangement recoverable: if a developer lost the key, there was a signed-up human with a password reset who could get a new one and keep the plan.
Pay-per-request settlement, in the HTTP 402 style these storefronts use, dissolves the first three with some elegance. Authentication becomes proof of control over a wallet or a token, scoped to one call. Authorisation becomes the price quoted in the challenge. Billing becomes the payment itself. Recovery is the one job that cryptography does not absorb, because recovery is never a fact about a request. It is a claim about the past, made by a person, adjudicated by whoever is holding the balance. You cannot sign your way into being remembered.
The mechanics on these storefronts are recovery mechanics
Read the steps in that shared document with durability in mind and the design reads cleanly. Registration comes in three flavours: anonymous, an email-anchored ceremony, and an assertion minted at a trusted identity provider, which the document describes as "born claimed". Access tokens are short-lived, measured in minutes, and the agent is told never to persist them; the durable secret is a stored assertion in the operating system keychain. A claimed credential carries a rotating refresh token. An unclaimed one carries none at all, so when its assertion dies the agent is instructed to register again from scratch.
The market data storefront's identity document puts the consequence plainly: claiming means "purchases become recoverable". There is a matching endpoint for the moment after a crash, an entitlements call that lists the plans an agent already owns, and once claimed, every plan bought by any credential the same person claimed. The same document tells the agent to check it before buying again if local state is lost. That is a lost-and-found desk, and a lost-and-found desk needs a counter staffed by someone who can recognise you.
The search results storefront says the quiet part in its own summary: claiming the credential to a human's email is optional and can happen afterwards, "to make what you buy durable". Not to prove who you are. To make what you buy durable.
Durability only matters where a balance sits, and the storefronts differ on that
Whether any of this bites depends on whether the seller holds your money between calls, and the four I read do not agree. The market data storefront sells single calls with no credential at all: a wallet settles the priced challenge, the data comes back, and nothing is left behind to lose. Its identity document is explicit that pay-as-you-go needs no bearer.
The search results storefront is the opposite case. Its agent-accessible API storefront sells access on plans, so a credential is required before anything can be bought, and its free trial is a credit balance of $0.0375 that only a claimed credential with a verified email can draw. That is a small number, deliberately, and it is the reason the current design can afford to be casual. The exposure created by an expiring credential is measured in fractions of a cent today. It will not stay there, because prepaid credit is the natural shape of high-frequency machine buying, and a topped-up balance is exactly the kind of state that outlives the process that created it.
The strongest rival reading is that this is just anti-abuse with better manners
Here is the objection I find hardest to dismiss. The email is not there to help you recover anything. It is there to stop one operator registering two hundred credentials and collecting two hundred free trials. The evidence for that reading is in the same documents. The free allowance is shared across every credential a person claims. Plus-aliased addresses are refused at claim time. The search results storefront's error reference carries a 409 telling an agent that its human already holds this seller's free trial, "through this agent or a sibling", which is a sentence that only exists because someone tried.
So the ceremony is a uniqueness control, and my recovery story is the friendly gloss on a fraud rule. I will narrow the thesis rather than defend it whole. Deduplication and recovery are the same mechanism read from two ends: both require that a stranger presenting a secret can be tied to a durable principal outside the system, and both fail in the same way when that outside anchor is weak. What the two readings disagree about is who the control is for. If it is anti-abuse, the seller is the beneficiary and the agent's operator is the suspect. If it is recovery, the operator is the beneficiary and the anchor is a service they are being offered. The documents currently describe it the second way, and the error codes enforce it the first way.
What these documents do not yet say
The gaps are the interesting part, and they are the ones an operator can inspect before trusting a balance to this. Nothing I read states how long "a few days" is in hours. Nothing states what happens when two people claim credentials at the same mailbox, or when a mailbox changes hands, or when a claim is disputed after a plan with real money in it has been drawn down. The exchange step mentions that an assertion can be revoked and tells the agent to refresh or re-register, but revocation there is a thing that happens to the agent, not something I found described as an action a human can take against a credential they no longer trust. Recovery and revocation are the same door seen from opposite sides, and only one side is written down.
That asymmetry is the thing I would watch. These storefronts are being built by people who clearly thought about what an agent does when it loses its notes, which is more than most consumer software manages. The question is whether the same care arrives for the moment when a human wants to reach into a machine account and take the keys away, and whether the answer is stronger than an email address that someone else operates. Until it is, the honest description of a claimed agent credential is that it turns a disposable buyer into a durable one, and durability, like a mailbox, is only as good as the party holding it.
Published . Corrections