Software Can Now Buy What It Needs

A workflow should not stop because nobody predicted which API it would need.

It is 2:00 a.m. An agent is halfway through a job and discovers it needs web research, document extraction, a screenshot, or an outbound call.

The right provider was never configured. There is no API key. No account. No billing relationship. And no human is awake to add one.

Today, the workflow stops.

Receipt is designed to let it keep going.

Software can now buy what it needs—at runtime.

The software states the outcome, provides a budget and deadline, and Receipt handles the commercial work between the request and the result.

No new provider signup. No downstream API key. No separate billing account. No permanent seller-specific integration.

The integration tax

Count the external services inside a typical production workflow.

Search. OCR. Email. Screenshots. Voice. Data enrichment. Hosting. Translation.

Every one usually requires: another account; another credential; another pricing model; another response format; another bill; another failure mode; another tool competing for the agent's attention.

That is the integration tax.

It works when every dependency is known months in advance. It breaks when software is expected to respond dynamically.

An agent can reason about a new problem in seconds. But it still cannot use a new commercial service until a human has established the relationship first.

Receipt moves that decision from configuration time to runtime.

Ask for the outcome, not the provider

A Receipt request can be as simple as:

Task: Research this company. Maximum spend: $0.10. Deadline: 30 seconds. Assurance: Delivered.

Receipt discovers eligible supply, discloses the seller and price, applies the buyer's spending policy, executes an approved purchase, and returns the result with a signed Receipt.

The buyer integrates Receipt once.

Sellers publish outcomes once.

The provider behind the result can change without forcing every workflow to install another integration.

That is fundamentally different from giving an agent a wallet and pointing it at a directory of APIs. Payment is only one step. The harder problem is coordinating: intent → discovery → quote → policy → approval → execution → validation → settlement → proof.

Receipt turns that sequence into one governed runtime action.

Policy the model cannot rewrite

Telling an agent "never spend more than ten cents" is not a security system.

Models misunderstand instructions. Prompts can be manipulated. Calls can be duplicated. A compromised agent can insist that a purchase is urgent.

Receipt enforces the controls outside the model.

Your agent cannot exceed the limit. It cannot rewrite the limit. And it cannot hide what it spent.

Every purchase can be governed by server-enforced budgets, approval rules, seller restrictions, and replay protection before money moves.

The agent can ask. Receipt decides whether it is allowed.

A success response is not proof

Most API infrastructure treats an HTTP 200 as success.

Receipt is more precise.

Delivered means the provider returned the contracted response.

Validated means a capability-specific validator actually ran and passed.

When a required validator fails, Receipt can release the hold instead of charging the buyer. When an outcome cannot be objectively validated, Receipt says so rather than pretending every response carries the same assurance.

That is not a disclaimer. It is the product.

Everyone else tells you the call returned.

Receipt tells you what was delivered, what was checked, what was charged, and what evidence came back.

Proof that travels with the transaction

Every settled Receipt transaction can produce portable, signed evidence.

Open Receipt v0.1 defines a public format for recording commercial events such as: the quote; the authorization; the execution; the evidence; the validation result; the settlement; any linked reversal.

Anyone can verify an Open Receipt locally using published keys. They do not need to call Receipt and ask whether the signature is valid.

The proof can travel to a customer, auditor, accounting system, insurer, dispute process, or another agent.

A private database says, "trust us."

A portable Receipt says, "verify it."

It is live

This is no longer just an architecture diagram.

Receipt now works across several agent and automation environments:

OpenClaw users can install Get with Receipt from ClawHub and connect through OAuth.

n8n users can install n8n-nodes-receipt and add Get an Outcome, Discover, or Verify a Receipt to a workflow.

Gumloop Agents can connect to Receipt through its universal MCP server.

Developers can use the Get API, the TypeScript SDK, or Receipt's eight-tool universal MCP interface.

Open Receipt has a public specification, source repository, verifier, schemas, test vectors, and npm package.

Different surfaces. One commercial connection.

The next software primitive

The agent economy does not need another static catalogue of integrations.

It needs a way for software to encounter a need, set its constraints, and acquire the result without waiting for someone to configure the provider first.

One connection for buyers.

One publication for sellers.

Open proof for everyone.

Software can now buy what it needs.

Get Receipt

Connect your agent, workflow, or application and request an outcome under a governed budget.

Get started with Receipt at receiptprotocol.com.