Builders, TrustPixel
Demand side · builders Participants / 01

Build agents that can complete the transaction.

Your agent can search. It cannot buy.

Completing the purchase means thousands of different suppliers, each with its own prices, its own checkout, and its own ways of failing. TrustPixel gives every agent one transaction interface.

1 · mandate issued, scoped and revocable
2 · offers returned, comparable, with an expiry
3 · transaction executed, receipt signed
Why now

Whoever solves this first ships an agent people actually trust with money.

Your agent found the flight.
Then it sent your user a link.

That link is where your product ends and someone else's begins.
Without a transaction layer
One integration per supplier, each with its own auth, schema, and failure modes
Policy expressed as prompt instructions the model may ignore
Payment credentials handed to an agent with no scope
Browser automation that breaks when a page changes
No defensible record of why a purchase was made
With TrustPixel
One purchasing API across every connected supplier system
Policy and budget enforced by infrastructure, before the decision
Spending capped by the rules you set, withdrawable at any moment
Purchases run in the supplier’s own system, with clear failures and defined recovery
A full audit record for every purchase
Capabilities

Five things your agent can do that it cannot do today.

Open any one for the technical detail.

The shift is not search. It is authority. Your agent carries a mandate, a signed and revocable permission to spend, enforced at every step rather than trusted to a model. No supplier API knows who your agent works for.

POST /v2/mandates
scope[] · cap · rules[] · expires_at
DELETE /v2/mandates/:id → <1s

One integration reaches every connected supplier, so your agent never meets a supplier-specific booking flow. Taxes, fees and change penalties resolve into one total with an expiry, so choosing is arithmetic rather than interpretation.

POST /v2/discovery
fanout 41 · p50 214ms · p95 480ms
offer.total_inclusive · components[]
offer.change_policy · expires_at

Every call is checked against the rules in force, not what the agent believes it was told. Ineligible options never become purchasable, so there is nothing to route around.

policy evaluated pre-decision
reasons returned per exclusion
cap tracks committed spend
escalate above threshold

Not one payment method: the right one for this purchase, chosen by policy rather than by whatever credential the agent happens to hold. The supplier is paid how it wants, and spending stays capped in one place.

payment.path: card | virtual_card
  | ach | invoice | wallet | split
selection: policy-driven
states: authorized → captured → settled

The room goes while your agent is deciding. The fare moves. A supplier times out mid-booking. Not retry logic: TrustPixel reports what failed, finds the eligible alternatives, re-prices, and stops for approval when the change needs one.

error.class: inventory_gone
  | price_changed | supplier_timeout
re-source · re-price · escalate
PATCH /v2/transactions/:id
In development
Not live today
Let your agent negotiate

Rates you already hold are applied today. Agent-to-supplier negotiation is bounded by the same authority.

Every transaction makes the next one better

Which payment path clears fastest, which recovery actually recovers. Outcome data only, never customer data.

Architecture

Where TrustPixel sits in your stack.

LAYER 1 · YOURS
Your agent runtime
Model, tools, memory, user interface. You own reasoning and product experience.
LAYER 2 · SHARED
Issuing mandates
Your customer or enterprise delegates authority. TrustPixel holds and enforces it.
LAYER 3 · TRUSTPIXEL
Exchange
Discovery, offers, policy, transaction, payment, proof, post-purchase operations.
LAYER 4 · SUPPLIERS
Supplier systems
Reservation systems, order management, ERP, fulfillment, settlement.
Example interaction
{{ tabDesc }}
{{ tabName }}api.trustpixel.com/v2
{{ tabCode }}
Interfaces & protocols

Reach the exchange the way your agent already works.

REST transaction APIv2 · stable
TypeScript and Python SDKstyped · retries built in
MCP servertools scoped to the rules you set
Open commerce protocolsoffer · mandate · proof
Webhooks and event streamat-least-once · signed
Sandbox

Supply that behaves badly on purpose.

Run a full transaction before you talk to a supplier. The simulated supply misbehaves on purpose: price changes, lost inventory, timeouts, policy rejections, partial refunds, withdrawn authority. Audit records come out exactly as in production.

sandbox keys · instant, no supplier contract
18 failure scenarios · deterministic replay
transaction inspector · full request trace
Get sandbox access

Start with the sandbox. Ship against real supply.

Start building View documentation Inspect a transaction