Submit
The prepared buyer application authenticates the data and operation using its registered source HMAC. The agent submits the prepared request.
B2B API · application HMAC · Ed25519 receipts
Verifiable Data Integrity Receipts
Share data with a signed proof of checks that a recipient can independently verify. IntegrityPhase checks authentication of the registered application, integrity of the submission, timestamp freshness and event and operation bindings. The receipt reports the checks and their outcomes; it does not prove real-world events.
webhook_integrity.v1
POST /verify/webhook-integrity
Access by B2B onboarding
REQUESTwebhook_integrity.v1payload · timestamp · application HMAC
RECEIPT verifiedEd25519 · request_id · artifact_hash
One product, one public operation
Application HMACTimestamp freshnessPayload fingerprintMachine-readable receipt
01
Defined verification flow
From application data to a signed check result.
Check
The service applies its method and release policy, checks the application HMAC-SHA256, checks timestamp freshness and calculates the payload fingerprint and size.
Receive
The agent keeps the operation identifier. If the request is accepted for processing, it checks status and retrieves the result later without another payment. Only a verified proof establishes the recorded check result.
02
Machine-readable receipt
Enough evidence to trace the check — without claiming more.
A released receipt identifies the method, request and technical artifact. It records the verification status, relevant check results, timestamps and fingerprints. Raw payload content is not part of the public receipt.
“Technical receipt” means the verification artifact returned by the API. It is not a payment receipt or invoice.
The receipt signature can be verified locally without calling the API, provided the correct IntegrityPhase public key and its matching key metadata were previously obtained through a trusted channel. Full verification of request, source and operation bindings also requires the original proof response and the corresponding original request data and identifiers. A key supplied alongside a receipt is not, by itself, a trusted key.
The receipt and necessary request data may be shared with an authorized customer, auditor or next agent for their own verification. Acceptance depends on the recipient; it is not automatic. Sharing requires neither the source HMAC secret nor a wallet private key.
- method, request and result status;
- artifact and proof identifiers with hashes;
- application HMAC and timestamp check outcomes;
- payload hash and size for correlation;
- explicit limitations and audit references.
{
"schema_version": "canon.verify_webhook_integrity_response.v1",
"request_id": "req_…",
"status": "verified",
"proof_released": true,
"artifact": {
"method_id": "webhook_integrity.v1",
"artifact_id": "whi_…",
"artifact_hash": "sha256:…",
"evidence": {
"signature_valid": true,
"timestamp_valid": true,
"payload_hash": "sha256:…"
}
}
}03
What is actually checked
A deliberately small verification surface.
IntegrityPhase reports only the checks executed by the configured method. It does not infer the business meaning of the payload.
Allowed operation
The method must be webhook_integrity.v1, and the configured policy must allow a technical artifact to be released.
Application HMAC and freshness
The application HMAC-SHA256 is checked using its registered source secret and the complete operation binding, including payload and timestamp. The timestamp must be parseable and within the configured age window.
Payload correlation
The service calculates a canonical payload hash and byte size so the checked input can be correlated without placing raw content in the receipt.
04
Automatic B2B onboarding
From company onboarding to a technical receipt.
The prepared agent uses its existing company authority and wallet through IntegrityPhase MCP, without a mandatory interactive setup. Qualified businesses in the 27 EU countries and supported VAT territories, including sole traders. Each buyer requires sufficient identity, tax and authority evidence. Unresolved qualification stops payment; consumers and private use are excluded.
EU BUSINESSES · 27 COUNTRIES- 01
Discover
Read
GET /.well-known/canon.jsonfor the request contract, eligibility, current availability and payment conditions. - 02
Onboard
Submit company and VAT details, the signed agent declaration and wallet signature through
POST /onboarding/b2b. Accept the exact Terms, Privacy Policy and framework DPA. - 03
Request verification
After qualification, obtain a current buyer-specific quote. Explicitly authorize its exact amount and submit once through IntegrityPhase MCP or direct HTTP with x402 support. Onboarding alone does not authorize spending.
- 04
Read the result
A
202 acceptedresponse confirms task acceptance, not settlement or a completed proof. Keep theoperation_idand SDK journal. Readoperation_status, then userecover_purchasefor the same operation. Verify the returned proof signature and its binding to the purchase.
While you wait: accepted and processing states mean the result is not ready. Respect the service-provided interval before the next status read. paused means execution is suspended, without a promised resumption time. pending_reconciliation means the settlement outcome needs reconciliation; do not submit another payment.
A refusal is not a completed proof. After completion, check the verification outcome separately: verified, failed or inconclusive. A completed operation may report a failed technical check. Status reads and recovery of the same operation do not initiate another purchase. After a network error, keep the identifiers and recover the existing operation when the service is available instead of paying again.
Access: The prepared joint launch covers direct HTTP, IntegrityPhase MCP and the buyer-selected Coinbase hosted proxy. Before submitting through the proxy, the buying company uses Coinbase in its own name through an authorised representative under the CDP Terms and Coinbase privacy information, separately from IntegrityPhase. Coinbase receives the full purchase request, including business data, identifiers, source HMAC signature and payment authorisation, and relays the response. Onboarding, the buyer-specific quote, status and proof retrieval use IntegrityPhase directly. A wallet or SDK does not establish company identity or authority. The same onboarding, document, budget and source controls apply. Preparation does not open sales; check current availability below.
Current sales availability is shown in the live-status panel. This informational site does not register a company, record acceptance or initiate a payment. View the applicable document versions. The API checks the signed declaration and key control; it relies on declared company authority and does not independently establish representation rights.
05
Explicit product limits
A technical receipt is not a truth certificate.
The result reports the checks actually performed and their outcomes. It does not confirm physical delivery, an actual reservation, the truth of an event, completeness of history or independently attested time. Timestamp freshness is a configured technical check, not independent time attestation.
The buyer application authenticates the submitted data and operation with HMAC-SHA256 using its registered source secret. This HMAC is distinct from the IntegrityPhase Ed25519 signature on the issued receipt. The current workflow does not automatically verify an original carrier or sender signature.
01
No guarantee that the underlying event, payload claim or source statement is true.
02
No qualified trust-service status or legal presumptions associated with a qualified service.
03
No guarantee of financial safety, payment finality, creditworthiness or business outcome.
04
No legal, tax, financial, investment, medical or operational recommendation.
05
No custody of customer funds, wallet/private keys or transaction-authorisation secrets and no participation in the customer’s underlying transaction.
06
The scope of each check is defined by the published method contract; a receipt is not a complete security audit of your integration.
06
Operational principles
Small surface. Clear evidence. Fail closed.
Receipt, not payload archive
Public output favors identifiers, timestamps and cryptographic fingerprints over raw customer content.
Linked technical records
Request, proof, artifact, ledger and audit references can be correlated without turning a technical result into a legal claim.
Missing conditions stop release
Missing access, policy, signature, timestamp or release conditions produce a blocked, failed or inconclusive result — not a successful receipt.
07
Integration support
Questions about your integration?
Contact us about the API, privacy or security. Company registration and document acceptance take place through automatic API onboarding.
sales currently disabled
Do not send payloads, API keys, wallet keys, payment signatures or other secrets by e-mail.
Company verification and agent purchases
Qualified businesses in the 27 EU countries and supported VAT territories, including sole traders. Each buyer requires sufficient identity, tax and authority evidence. Unresolved qualification stops payment; consumers and private use are excluded. EUR 10 net per proof plus applicable VAT. USDC on Base uses the current buyer-bound quote using the daily rate prepared before readiness and valid until Warsaw midnight. A technical proof does not confirm order fulfilment. Sales availability and dated Bazaar observations are separate. Nevermined is OFF.
IntegrityPhase issues a signed result of checks on data submitted by a registered application, bound to the source and operation. The buyer application authenticates the submitted data and operation with its registered source HMAC; IntegrityPhase signs the check result with Ed25519. This workflow does not automatically verify an original carrier or sender signature. For example, a logistics, warehouse, supply-chain or MRO application may submit order-acceptance, parts-reservation or inventory-update data. The result does not prove physical stock, fulfilment or the underlying real-world event. No ERP integration is claimed.
IntegrityPhase — Verifiable Data Integrity Receipts
Signed proof
Ed25519 signs the actual check results, including negative or inconclusive results. Every receipt costs EUR 10 net plus applicable VAT.
Data integrity · tamper-evident
Verification detects changes that break the proof signature or the consistency of covered data and bindings.
Source authentication
The registered application HMAC check does not verify a carrier signature, original device or person identity. Freshness checks compare the submitted timestamp with the permitted window; they do not attest the real age of information or independent time.
Offline verification
Keep the complete proof and completion binding, original data and request context, canonical hashing rules, and an independently trusted IntegrityPhase public key with matching key metadata. A bundled key alone is not trusted. Verifying the signed result does not repeat the source HMAC check without its secret. Never share source secrets or wallet private keys.
Audit trail
The signed event and operation record helps compare data and explain differences. It does not promise complete history, continuous upstream custody, the location of tampering or responsibility. Acceptance depends on the recipient.
Two event kinds, one price
EUR 10 net for every proof, with no percentage fee. Polish VAT 23%: EUR 2.30, total EUR 12.30. Qualified reverse charge: EUR 10 with the applicable tax annotation. Non-monetary events omit amount and currency. Transaction events declare EUR 100–300 inclusive. Every event has its own identity; several statuses may reference the same business object. The proof purchase has a separate identifier.
Logistics: shipment status
{"event_kind":"non_monetary","payload":{"shipment_ref":"parcel-42","status":"reported_delivered"}}
Data from a reported order acceptance, shipment status or IoT report. Does not attest physical delivery or measurement authenticity at the original device.
Production: quality report
{"event_kind":"non_monetary","payload":{"batch_ref":"batch-7","check":"visual","result":"pass"}}
Integrity of a submitted quality or nonconformity report. Does not assess component quality or certify compliance with a standard.
MRO: maintenance log
{"event_kind":"non_monetary","payload":{"object_ref":"device-8","action":"inspection_recorded"}}
Data from a reported parts reservation, inventory change or maintenance log. Does not confirm an actual reservation or completed repair.
Integrations and agents: API result
{"event_kind":"non_monetary","payload":{"task_ref":"task-9","status":"completed","output_hash":"example-hash"}}
Submitted statuses, logs, notifications, reports and API or agent results require a registered source. No guarantee that the agent acted correctly.
Transaction event: order
{"event_kind":"transaction","event_value_eur":150,"event_value_currency":"EUR","payload":{"order_ref":"order-10","status":"accepted"}}
Declared value EUR 100–300, separate from the proof price. Does not prove payment or fulfilment; safety-critical use exclusions remain in force.
Checks cover the registered application HMAC, integrity, freshness and signed data bindings. They do not confirm external facts, payment or continuous custody of an entire data chain. Verifiable Credentials, chains of proofs and asymmetric customer source signatures are outside scope.
Availability and observations
Sales: no current confirmation.
Bazaar: no current observation.
Nevermined: OFF.