Postman already owns the hard part: the MCP Server gives AI agents trusted access to the full Postman platform — collections, specs, environments, workspaces, mock servers, and monitors exposed as 100+ tools an MCP-compatible agent can call over HTTPS or local stdio. Hive doesn’t re-run any of that. Hive takes each agentic API operation Postman already lets an agent perform and turns it into an independently signed, portable receipt under a post-quantum signature — so an operation becomes provable to an auditor, a platform owner, or a downstream consumer, long after the agent moved on.
Figures and capabilities above are Postman’s own published descriptions, cited from the Postman product page and engineering blog (postman.com/product/mcp-server, blog.postman.com) — described by Postman, not asserted by Hive. They show the scale at which agents already operate the API lifecycle inside Postman; Hive’s role is to make that operation provable.
An MCP-compatible agent calls Postman tools — workspace, spec, collection, environment, mock, tests, monitor. Each operation crosses the same independent Hive rail on its way to a signed, portable receipt. Illustrative visual of the rail; not live production traffic.
Postman supplies the platform and the agent’s access to it; Hive supplies the independent proof of what the agent did. Keeping the two roles separate is exactly what makes the proof worth anything to a security team, a platform owner, or a downstream API consumer.
The MCP Server lets an agent operate collections, specs, environments, mocks, and monitors as tools. That operation is Postman’s to enable — Hive never invokes the tool or changes the API artifact itself.
An activity log the platform writes about its own agent traffic is credible but self-referential. An independent receipt — signed by a party with no stake in the operation — is what an auditor or consumer can treat as evidence rather than assertion.
Hive signs the attested operation — agent + tool identity, workspace/collection/env target, approval gate, and artifact hash — under ML-DSA-65 (NIST FIPS 204). It attests operations, never a verdict on whether the API change was correct.
Postman’s platform logs and workspace state are rich and useful — but they live inside Postman and describe Postman’s own agent traffic. This isn’t about whether Postman has logs or security — it does. It’s about handing a downstream consumer, auditor, or partner independent provenance they can verify without access to your Postman.
Pick a surface. Each shows what Postman already lets agents do (with its own published capabilities), the one place a durable-proof gap tends to open, and the Hive receipt that closes it. Nothing here changes Postman’s platform — the receipt wraps around the operation the MCP Server already exposes.
The MCP Server exposes collections as tools an agent can read and modify — creating, updating, and organizing requests across a workspace as part of the API lifecycle (source 1).
The collection’s new state is visible, but there is no independently signed record per change of which agent and tool made it, against which workspace, and under which approval — the trail a security review or consumer asks for.
A signed collection-operation receipt binds agent + tool identity, the collection/workspace target, and the before/after artifact hash under ML-DSA-65 — verifiable offline, no access to Postman required.
Agent Mode can generate MCP servers for internal APIs (beta) and the MCP Generator does so for public APIs; agents can turn an OpenAPI spec into a collection with the platform (source 1).
A generated spec or server becomes part of your API supply chain. Which agent generated it, from which inputs, and who approved it is exactly what a downstream consumer wants provenance on — not a reconstruction after the fact.
A generation-provenance receipt seals the input hash, the generating agent/tool identity, and the output artifact hash into one signed, exportable object — provenance for the generated spec or server, re-verifiable independently.
Agents can stand up mock servers from a collection through the MCP Server, letting downstream work proceed before a real API exists — part of the headless lifecycle Postman describes (source 2).
A mock silently shapes what other teams and agents build against. The per-operation trail — which agent created or updated the mock, from which collection version, and when — isn’t an independently signed artifact.
AFiR emits an independent ML-DSA-65 receipt for each mock operation — agent identity, source collection hash, and change — tying the mock the world builds against to the agent that shaped it.
Agents can write tests and stand up monitors through the MCP Server, completing the spec→collection→mock→tests→monitor lifecycle without opening the app — in roughly ten minutes of prompting (source 2).
A monitor exists, but demonstrating that a specific test suite or monitor was actually created by an authorized agent, on which collection version, under which policy — not just that it exists — is the hard part for an auditor.
A test/monitor-provenance receipt signs the source collection hash, the creating agent/tool, and the created artifact — assembling into an audit-ready bundle exportable as one verifiable package.
The MCP Server exposes environments and workspaces as tools an agent can read and change — variables, scopes, and workspace organization that shape how every request resolves.
An environment change can quietly redirect where agents send traffic. The change should be provably attributable to a specific agent and approval — tied to the workspace state before and after, not inferred later.
An environment-change receipt binds the agent identity, the variable/scope delta hash, and the approval gate — so a change to where traffic goes is provably attributable. Hive attests the change, never whether the config is correct.
Runs MCP-compatible agents against 100+ tools across the platform, with tool calls counting toward API plan limits — a rich internal graph of which agent invoked which tool.
That graph lives in Postman’s systems. Once an artifact leaves — to a consumer, an auditor, a partner — which agent, which tool, which approval is no longer independently checkable.
Every Hive receipt carries agent identity, tool identity, and approval gate as first-class signed fields — the shared spine beneath collection, spec, mock, test, and environment receipts alike.
Postman describes agents driving the full lifecycle — OpenAPI spec → collection → environment → mock → tests → monitor — without opening the app (source 2). Run the sequence to see where an independent Hive receipt seals each operation. Illustrative run — receipts wrap operations Postman already performs; the visual is not live production traffic.
Each hop emits an independent ML-DSA-65 receipt binding agent + tool identity, the source artifact hash, and the created artifact — operations, never a verdict.
A sample of signed operation receipts an agent’s headless lifecycle would produce. The values below are illustrative example data, not live Hive receipts — a native, browsable receipt explorer inside Postman is an Act II candidate (see below), not a live surface today.
| Operation | Agent · MCP tool | Target | Artifact hash | Signature | Status |
|---|---|---|---|---|---|
| createWorkspace | agent · workspaces | ws:payments-api | 9f2a1c…b4e0 | ML-DSA-65 | signed |
| createApi | agent · api | api:orders v1 | c41b7d…22af | ML-DSA-65 | signed |
| createEnvironment | agent · environments | env:staging | 7de0a9…1f3c | ML-DSA-65 | signed |
| createMock | agent · mocks | mock:orders | a835e2…90d7 | ML-DSA-65 | signed |
| updateCollectionTests | agent · collections | col:orders-tests | 22f7bc…5e11 | ML-DSA-65 | signed |
| createMonitor | agent · monitors | mon:orders-health | e10c48…7a6b | ML-DSA-65 | signed |
To see a real signed receipt today, run the free live demo at /model-receipts/ or verify one at /verify/. Each receipt attests the operation — never a verdict on whether the API change was correct.
Every Hive receipt is signed with ML-DSA-65 (NIST FIPS 204 post-quantum signature) and is dual-signed alongside Ed25519. Tap a Postman workflow to see which primitives apply; the matching cards light up green.
Enter your own assumptions to estimate the operational proof footprint — how many signed provenance events a receipted MCP deployment would produce and export. This is a planning estimate, not a quote: no revenue, pricing, or economics, just receipt volume.
Click the operations a pilot would sign across a headless API workflow. Each component adds its fields to the exportable provenance bundle preview — the same shape a consumer or auditor would re-verify offline.
Click any step to see exactly what evidence Hive signs there. The operation and the platform are Postman’s; the signature, portability, and export are Hive’s.
This hits Hive’s public, no-auth x402 quote endpoint and returns a live settlement envelope with an ML-DSA-65 (FIPS 204) signed quote receipt. No key, no secret, nothing to install. To see signed receipts for real model calls, run the free live demo at /model-receipts/.
curl -sS -X POST https://receipts.thehiveryiq.com/v1/x402/quote \ -H 'Content-Type: application/json' \ -d '{"agent_did":"did:example:postman-agent","profile":"nano"}'
The response includes the rail (USDC on Base 8453), a signed quote receipt, and its ML-DSA-65 / FIPS 204 post-quantum posture. To emit a paid receipt end-to-end, walk the live flow at /x402-checkout/; to start a pilot, request an activation key at /activate/. No secrets are ever placed on this page.
Anything a developer triggers — an API call, an x402 gate, a wallet call, an MCP action, or a stablecoin transfer — can emit a portable, independently verifiable Hive receipt, and drop straight into a collection or a test run. Stablecoins move value. Hive proves the intent, actor, policy, receipt, settlement state, and recoverability window around that movement.
Intent receipt: actor, amount, asset, recipient, policy context, authorization state — signed before the request fires.
Submitted, relay-observed, chain-pending, escrowed, quarantined, or an issuer/custodian hold requested — each state receipted.
Chain-verified, receiver-attested, counter-transfer initiated, evidence-only, or a recovery bundle exported for a dispute or examiner.
Emit a receipt for a payment intent or event through the public Receipt Relay — no key, self-attested tier, ready for a Postman collection:
curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \ -H 'Content-Type: application/json' \ -d '{"action":"stablecoin_transfer","external_system":"usdc", "actor":{"did":"did:example:postman-agent"}, "payload":{"asset":"USDC","amount":"25.00","from":"0xSender","to":"0xRecipient","network":"base"}}'
The relay grades evidence honestly: self_attested signs your described intent as-is; relay_observed is only issued when Hive itself made the outbound call (/v1/receipt-relay/http); chain_verified only when a tx is read back from a public RPC (/v1/receipt-relay/chain). A Circle/USDC-compatible schema is live today — this service never calls Circle APIs; a direct Circle integration is a next-stage partnership. Verify any receipt at /verify/; search and export in Hive Ledger.
A receipt is a machine-readable proof-state object. A collection, a test run, or an agent workflow emits a graph of receipts — each request, gate, and payment as its own signed node. Hive Ledger derives an R3Pv: a Receipt Relay, Recovery, and Routing Proof Vector over that graph, encoding verification, policy, economic, recoverability, routing, performance, risk, and permitted-next-action state — so the workflow itself can decide what to do next.
Verification and policy fields say whether the next step is cleared to run or should halt — an x402 or API payment gate that failed to receipt is a stop, not a silent retry.
Routing and risk fields can send a step to a fallback provider, a different MCP tool, or a human-approval hold — the decision, and its reason, are receipted.
The recoverability field carries the rail-specific window; when a run needs proof, the vector exports as a signed bundle straight from Hive Ledger.
The proof vector is now a live callable primitive — group signed receipts with POST /v1/r3pv/groups, then GET /v1/r3pv/vector?group_id=… returns a single Ed25519-signed vector that itself round-trips POST /v1/receipt/verify. This is a real signed response from production:
{
"signed_vector": {
"vector_id": "r3pv.vector_1783314171_1943fee9f9ba",
"payload_sha256": "d7f0a1c8…",
"sig_b64u": "MOd0rX… (Ed25519)",
"key_id": "did:hive:hivemorph",
"algorithm": "Ed25519",
"vector": {
"schema": "r3pv-v1.0.0",
"verification_depth": "self_attested", // strongest tier in the group
"weakest_proof_boundary": "self_attested", // group is only as strong as its weakest link
"healing_state": "not_applicable",
"economic_exposure": { "inferable": false }, // relay receipts store intent_hash, not cleartext
"policy_state": "not_evaluated",
"routing_recommendation": "require_approval",
"permitted_next_actions": ["hold", "require_approval", "export_evidence"]
}
},
"verification": { "ok": true, "verify_endpoint": "/v1/receipt/verify" }
}
Result: GET /v1/r3pv/health → HTTP 200 (engine r3pv, schema r3pv-v1.0.0, signer did:hive:hivemorph, 11 healing states); POST /v1/receipt-relay/event → 200 signed receipt; POST /v1/r3pv/groups → 200; GET /v1/r3pv/vector → 200 signed vector (verification.ok=true, Ed25519); POST /v1/receipt/verify on the vector → 200 verified=true, signature-verified. Observed client round-trip 0.10–0.50s including network, TLS, and edge — not a signing benchmark. Measure receipt latency separately from settlement / rail latency.
curl -s -o /dev/null -w '%{time_total}s %{http_code}\n' \ https://receipts.thehiveryiq.com/v1/r3pv/health # sign a receipt, keep the receipt object curl -sS -X POST https://receipts.thehiveryiq.com/v1/receipt-relay/event \ -H 'Content-Type: application/json' \ -d '{"action":"api_call","external_system":"postman", "actor":{"did":"did:example:postman-agent"}, "payload":{"method":"POST","url":"https://api.example.com/pay","x402":true}}' \ | python3 -c 'import sys,json; json.dump(json.load(sys.stdin)["receipt"],open("r.json","w"))' # group it → group_id, then generate + sign the proof vector GID=$(curl -sS -X POST https://receipts.thehiveryiq.com/v1/r3pv/groups \ -H 'Content-Type: application/json' \ -d "{\"label\":\"postman\",\"receipts\":[$(cat r.json)]}" \ | python3 -c 'import sys,json; print(json.load(sys.stdin)["group_id"])') curl -s -w '\nvector %{time_total}s %{http_code}\n' \ "https://receipts.thehiveryiq.com/v1/r3pv/vector?group_id=$GID"
Download the Hive R3Pv Postman collection — six runnable requests against the live primitive: (1) GET /v1/r3pv/health, (2) sign a stablecoin-transfer receipt (no funds move), (3) sign an agentic api_call receipt, (4) team receipts into a group via POST /v1/r3pv/groups, (5) generate the Ed25519-signed proof vector via GET /v1/r3pv/vector, (6) verify the vector itself at POST /v1/receipt/verify. Requests chain automatically — request 2 stashes the receipt, request 4 captures the group_id, request 5 captures the signed vector, request 6 proves it verifies.
Every action below hits a real, running Hive surface. Start with one paid receipt, test a model receipt for free, or request an activation key to scope a pilot.
Act I receipts the agentic API operations Postman already lets agents run — making today’s MCP traffic independently provable. Act II points the same independent proof layer at what Postman is building toward: agents that operate the entire API lifecycle headlessly (source 2). These are strategic options to weigh, not a claim that everything is live today.
Candidate line 01
Hive attests the operation and its provenance — never that the API design was right. That honest boundary is what keeps it credible to a consumer.
Candidate line 02
The provenance is the product; the receipt is the artifact that survives a supply-chain review.
Candidate line 03
A verifiable operation graph is a candidate surface; the receipt graph is the audit trail.
Candidate line 04
x402 settlement and signed receipts are live; specific third-party agent-platform integrations are labelled as fast-follow, never asserted as shipped.
Act I proves what Postman’s agents run today. Act II points the same independent proof layer at where Postman is heading — each a strategic option to weigh, harder to replicate because independence can’t be self-supplied, and none of them a claim that the line is live today.
Postman operates. Hive proves. Together the API lifecycle isn’t only automated — it’s independently provable.
Every link below is a real, running page — not a mock.
Public references for the Postman statements cited above. Where capabilities appear on those pages, treat them as source-described by Postman, not asserted here.