Skip to content

// Developers

Build with MidPledge

Your agent states intent. Authority is resolved at the source and verified by the party that relies on it.

One model for agents whose consequential actions — API calls, data release, orders, commitments, sub-agent delegation — must be verifiable outside your own stack.

See the transaction lifecycle
Example request
// the agent describes what it wants to do
// — it never asserts what it is allowed to do
POST /transactions
{
  "agent":         "agent-27",
  "relying_party": "supplier-b",
  "action":        "PURCHASE_ORDER",
  "target":        "PO-4471",
  "amount":        { "value": 6000, "currency": "USD" }
}
01

Authority sources

Principal-authorized systems and evidence that define what an agent may do.

02

Transaction binding

Authority tied to one exact action under an MP-TX reference.

03

Verify

The relying party's own call, with what it received, before it accepts.

04

Current authority state

Active, revoked, expired or approval-required now — UNVERIFIABLE when it can't be established.

05

Authority Transaction Records

Append-only evidence of what was authorized, accepted and executed.

06

Protocol & evidence adapters

How platforms, credentials and protocols become verification inputs.

// Transaction lifecycle

Five calls, three parties

A conceptual lifecycle, shown with a purchase-order example. Endpoint names and fields are examples and may change.

Conceptual examples · not a published API reference
POST /transactions
// request — agent (authenticated as itself)
{ "relying_party": "supplier-b", "action": "PURCHASE_ORDER",
  "target": "PO-4471", "amount": { "value": 6000, "currency": "USD" } }

// response — authority resolved from Company A's authorized source
{ "transaction_id":    "MP-TX-8F21C4A9",
  "principal":         "company-a",
  "authority_source":  "principal-authorized-source",
  "authority_version": "v12",
  "authority":         "AUTHORIZED",
  "tx_digest":         "sha256:3f9a…e04c" }
// request — Supplier B, with the details it actually received
{ "action": "PURCHASE_ORDER", "target": "PO-4471",
  "amount": { "value": 6000, "currency": "USD" } }

// response — current state, checked now
{ "result":          "AUTHORIZED",
  "binding":         "MATCH",
  "authority_status": "active",
  "verified_at":     "19:10:31Z" }
// mismatched amount → "BINDING_MISMATCH" · revoked → "AUTHORITY_REVOKED"
// Supplier B records its own decision
{ "decision": "ACCEPTED", "reason": "within_credit_terms" }

// MidPledge never makes this decision for the relying party
{ "recorded": true, "at": "19:10:33Z" }
// execution outcome from the system that executed
{ "type": "EXECUTED", "external_ref": "so_99213" }

{ "recorded": true, "at": "19:12:50Z" }
{ "transaction_id":  "MP-TX-8F21C4A9",
  "authority":       { "source": "principal-authorized-source", "version": "v12", "decision": "AUTHORIZED" },
  "relying_party":   { "verify": "AUTHORIZED", "decision": "ACCEPTED" },
  "execution":       "EXECUTED",
  "tx_digest":       "sha256:3f9a…e04c",
  "evidence_digest": "sha256:a90f…44d2",
  "signature_ref":   "sig:mp-key-01",
  "integrity":       "VERIFIED" }
Advanced · protected fields & binding rules

Protected fields

Authority bound to one transaction — not just an agent

principalCompany A agentProcurement-Agent-27 relying_partySupplier B actionPURCHASE_ORDER targetorder #PO-4471 amountUSD 6,000 conditionsapproval > 7,500 authority_sourceprincipal-authorized authority_versionv12 valid_at19:10:04Z approval_statenot required

MidPledge transaction binding

MP-TX-8F21C4A9

tx digest sha256:3f9a…e04c

! Change a protected field — action, counterparty, value, conditions — and verification returns a binding mismatch, or a new transaction is required.
i The transaction ID is a reference, not an authorization token. Holding it grants nothing; the relying party still verifies.

// Where your stack ends

Your controls govern inside. Others need to verify outside.

OAuth scopes, API keys and policy engines describe access inside your boundary. A counterparty can't see them — and shouldn't need a bespoke integration with each of them.

Discuss a developer integration

Developer integration is discussed with the MidPledge team and scoped to your actions, authority sources and relying parties. An inquiry starts a conversation; it does not issue credentials or self-service access.