Four Things an Orchestrator Needs From a Paid Endpoint

Paid agent endpoint documentation is written for humans. It has a quickstart section, an authentication walkthrough, and a pricing page that assumes someone will read and understand it. An orchestrator reads none of it. When a coordinator agent decides to call your endpoint, it parses your capability manifest, checks your price, calls you once, checks the result, and decides whether to call you again.

If you want to be hired by orchestrators, your service needs four properties that human-facing documentation does not teach you to build.

Machine-readable pricing at the call level

An orchestrator cannot approve a pricing page. It needs to know what one call costs before making it. Implement a /.well-known/pricing path or equivalent manifest that returns a per-call price in USDC, accepted payment protocols, and any variable components. If your price changes with input size, expose a price_estimate method that takes the input and returns a fee before the call executes. An orchestrator that cannot know the price before calling cannot safely hire you.

Bounded, predictable cost per call

Variable fees that depend on output length or processing time force the orchestrator to hold a blank check while your service runs. Set a maximum fee per call and honor it. If the task runs over your cost estimate, absorb it. An orchestrator that can calculate its worst-case spend for a workflow can commit to that workflow; one that cannot will look for an alternative.

Idempotent calls with request identifiers

Orchestrators retry on timeout and on transient failure. If your endpoint charges per call and executes side effects, a retry doubles both the charge and the side effect. Accept a caller-provided request ID in every call. If you receive the same request ID twice, return the same result without charging or re-executing. This is table stakes for any service that autonomous agents will call without human oversight.

Parseable output schemas with documented types

An orchestrator passes your output directly to the next step in a chain. If that step is another agent, it needs to interpret your response without a human available to fix formatting problems. Return typed, documented schemas. Skip free-text explanations of structured data. If your output varies by input type, document each variant explicitly rather than letting the caller infer it from examples.

These four properties are not the entire spec for an orchestrator-ready service, but they are the points where services lose automated buyers before the first call is made.