Provably.
Verify the decision.
Bind it to the transaction.
Provably records signed provider decisions and checks transaction-bound x402 payment proofs. Public receipts expose a limited status projection; the security page documents provider dependencies, token limits, and the feature-flagged proof prototype.
Account access and sandbox credentials are separate. Creating an account does not issue an API key.
Why Provably
Transaction checks for
human-AI workflows.
Provably verifies configured provider callback signatures, binds x402 payment proofs to transaction IDs, and exposes a limited receipt. It does not prove a transaction's commercial terms or guarantee settlement.
- Provider signatures are checked before callback decisions update a record.
- Payment proofs are bound to the transaction named in the request.
- Public receipts omit provider evidence, bearer tokens, and raw payloads.
How it works
Four steps. One transaction-bound check.
Current request, callback, and receipt behavior is described in the security dossier.
Start with a transaction ID
POST /api/verify begins with a transactionId. Without payment proof, the API returns a 402 challenge describing the accepted payment method.
Validate the payment proof
The current gate matches the request and proof transaction IDs, checks the quoted amount and payTo address, and verifies HMAC-SHA256. A facilitator is used only when configured.
Record the provider decision
A provider webhook signature is checked before its decision is normalized to pending, verified, or rejected.
Read the result
GET /api/verify returns the current status. The public receipt shows status, verifiedAt, and x402PaymentId—not the underlying provider record.
Illustrative integration patterns
Examples to evaluate against your own workflow.
These are possible integration patterns, not claims about current customers or live partner deployments.
Attach a delegation to a verified human record
The current endpoint stores a supplied agent ID, signature field, and expiry under a verified human record. Active listings filter by expiry; there is no manual revocation or scope-enforcement endpoint.
Pricing and access
Ask for current commercial terms.
This site does not publish validated rates, plan limits, or a checkout flow. Sandbox credentials require a separate request; creating an account does not issue an API key.
FAQ
Things engineering teams ask on the first call.
Review how the current API checks payment proofs, records provider decisions, and limits its public receipt.
What does Provably verify, exactly?
The current provider path verifies configured callback signatures and records a canonical pending, verified, or rejected decision. Separately, POST /api/verify checks an x402 proof bound to a transactionId and returns a VERIFY bearer on the verified path. This does not prove that arbitrary payload terms were signed.
Is Provably a blockchain or a wallet?
No. Provably does not operate a blockchain or wallet or custody funds. The /api/verify route validates a payment proof and calls a facilitator only when one is configured. Without a configured facilitator, a passing local proof check is not proof that an external rail settled funds.
How does it interact with AI agents?
A verified person can send agent IDs, supplied signature fields, and expiries with their VERIFY bearer to /api/delegations. The app stores those records against that verified human and lists records whose expiry is still in the future. The current API has no manual revocation or explicit scope enforcement.
Get started
Provider decisions · transaction-bound x402 checks · limited public receipts
© 2026 Provably · provably-2@polsia.app