Pricing as an API

>_GET /blog/pricing-as-an-api

Fit>_Fit protocolPOST /fitThe demand-side mirror of the manifest — an RFP turned into an API with structured briefs and verdicts.defined in Does this actually fit? → told Blake whether Sam maps onto the company's needs. The manifest>_Capability manifestGET /.well-known/agent.jsonThe missing middle layer between OpenAPI and schema.org — a signed business datasheet agents can parse.defined in The end of landing pages →'s other pointer, pricing, tells it what that costs. Following it today usually leads somewhere useless: a page with three tiers and a fourth that says Contact sales. A human reads "contact sales" as an invitation. Blake reads it as a wall, and a wall is a signal: the price is hidden because it is negotiable, which means it is personal, which means it is a risk to be priced in.

To be fair, "contact sales" isn't an oversight. It's a strategy. It lets a vendor charge each buyer what that buyer can pay, and it earns real margin. Nobody abandons that out of goodwill, and nobody expects them to. The claim is narrower: once the buyer treats opacity as a risk and prices it in, the extra margin from hiding the price gets wiped out by the deals you lose because you hid it. The wall stops paying for itself.

An agent cannot make a decision it has to answer for on top of "it depends, let's talk." It needs a number it can request, compare, and commit to within seconds rather than over a sales cycle. So pricing stops being a page and becomes an endpoint. And the moment it does, something deeper than formatting changes: the nature of selling changes with it.

This post is about what a price looks like when the buyer is a machine: a quote engine instead of a page, a function instead of a table, and (the real shift) two agents negotiating where a salesperson used to stand.

From a pricing page to a quote engine

The model already exists in finance, if not yet in SaaS. A request-for-quote (RFQ) market is exactly this: you send parameters, a dealer answers with a firm price valid for N seconds, and you take it or pass. Airlines and FX desks price dynamically and bindingly thousands of times a second. Airlines, of course, are also the textbook case of dynamic pricing used against the customer. The precedent cuts both ways, and we'll deal with that specific trap below. Even in our world the machine-readable half is here: the AWS Price List API turns a catalog into something a machine can read.

Pricing-as-an-API brings that to software. Blake sends the company's parameters (volume, seats, geography, term) and gets back a structured, binding quote. The key word is binding. A quote has to be signed and time-limited, like a dealer quote with an expiry, so Blake can treat it as a commitment instead of an "estimate." Here the identity layer pays off again: the quote is signed with Sam's key and carries a valid_until, so Blake can rest a decision on it.

A signed quote

{
  "quote_id": "q_8f3a…",
  "base": "2400 EUR/mo",
  "tco": {
    "license": "2400 EUR/mo",
    "overage": "0.004 EUR / record > 500k",
    "onboarding": "1500 EUR one-time",
    "egress": "0 EUR",
    "support_premium": "+15%"
  },
  "pricing_model": "https://sam.example/.well-known/pricing/model",
  "renewal_cap": "<= 7% / yr",
  "sla": "vc://sla-99.9",
  "valid_until": "2026-07-15T16:53:00Z",
  "signature": "ed25519:…"
}

Three things in here matter more than the headline number.

Total cost over time

What Blake buys is total cost over time, so the pricing_model link has to expose the formula, not just one point on it. The question Blake actually needs to answer is "what happens at 10× the volume next quarter?", and without access to the marginal cost of scaling it cannot judge that. A low entry price that explodes at scale is worse than a higher one that stays flat, and only a function reveals which is which.

Metered by default

Agents push the market from subscriptions toward usage-based billing (per call, per record, per token) because an agent can continuously optimize consumption in a way a human team never could. That demands a real-time metering and billing API, so Blake can see the running cost and tune it. Subscriptions do not vanish, but consumption becomes the default unit of account.

Beyond the license fee

The license fee is rarely the real cost. Overage, onboarding, egress, minimum commitments, auto-renewal, the cap on annual increases: these are the line items that hide in a PDF today and blow up a budget a year later. Blake demands them explicitly in the quote. A vendor that buries them looks risky rather than cheap, and the gap becomes a reputation penalty the moment Blake finds it.

The real shift: machines negotiate

Here is the part that retires the salesperson. A deterministic price API makes agent-to-agent negotiation possible. Sam's principal sets a policy: a floor, a maximum discount, and what can be traded (a longer term for a lower price, a bigger commitment for a rebate). Blake carries its own mandate from the company. Two bounded optimizers meet and bid in a loop, in seconds:

Blake → Sam: "12m at 2400? I'll commit to 24m for 1950/mo."
Sam   → Blake: "Floor at 24m is 2100. I can add free onboarding."
Blake → Sam: "Done: 2100 + onboarding + a 5% renewal cap."
Sam   → Blake: "Agreed. Quote signed, valid 60s." → contract

Because this is a repeated game, reputation disciplines both sides: Blake cannot sandbag forever and Sam cannot fake scarcity, since either move shows up in the transaction history that feeds the reputation layer>_Proof of transactionReputation from signed receipts and SLA history — not reviews, opinions, or star ratings.defined in Reputation as capital →.

The dark side: algorithmic price discrimination

There is a real hazard here. Because Sam reads Blake's manifest and identity, it can infer that the company can pay more, is desperate, or is locked in, and quote a personalized, inflated price. Dynamic pricing cuts both ways. Blake's defenses are concrete:

• Reference prices. It compares the quote against a market benchmark from the registry or reputation layer; a glaring deviation is a warning flag.
• An MFN clause. It asks for a most-favored-nation guarantee: "no worse than any comparable customer with this profile and volume."
• Anonymous discovery. At a low assurance tier>_Proportional assuranceTiered proof: did:web for low stakes, full chain for contracts — assurance scales with stakes.defined in Are you really you? → it asks for a price without revealing who the company is, to see the list price before personalization.
• Reputation. Vendors known for gouging simply rank lower.

The resolution is a split: a transparent, deterministic list price plus negotiated discounts that are bounded by policy and disclosed. Honest segmentation (a stated cost-to-serve factor like EU residency) is fine; inferring desperation and pricing it in is what gets punished.

How Blake consumes it

1. It calls the pricing API with the company's parameters and gets back a signed quote.
2. It verifies the signature and the valid_until against the identity layer.
3. It pulls the pricing_model and models TCO over time and the marginal cost of scaling.
4. It compares against a reference price to detect discrimination.
5. If there is room, it negotiates inside the company's mandate.
6. It checks how the price couples to the SLA and the payment rail.
7. It decides, and the result becomes a signed term it can monitor.

Bets worth placing

Start even lower than an API. At Brand24, we published pricing.md beside the pricing page: a machine-readable copy of the parts we can state without a sales call. Leave "contact sales" where a deal still needs a person. Publish the deterministic part as a document, watch the logs, and see whether agents read it.

If the file gets read, place the next bet: expose the same rules as a quote endpoint and return a number the buyer can store. Then sign the number and give it an expiry. Then force the quote to include the parts people usually hide: overages, onboarding, renewal caps, SLA credits. Only after that do the larger market bets make sense: MFN guarantees you can prove, reference-price oracles, negotiation protocols, and payment rails for escrow or usage settlement. Each layer should earn its way in the logs. A price without a way to commit to it, compare it, or pay it is still just content.