Documentation Index
Fetch the complete documentation index at: https://developer.prove.com/llms.txt
Use this file to discover all available pages before exploring further.
ProveX solution
With ProveX, you can keep helping consumers when they still need to take action in your product—such as funding an account or choosing how to pay. Instead of sending them elsewhere or rebuilding separate integrations for every data source, you surface Prove partner capabilities through a consistent pattern so the handoff feels like one journey. That means fewer abandoned flows, less custom plumbing on your side, and a clearer path for customers to finish what they started. Architecturally, ProveX is a Prove-mediated marketplace layer: once the consumer has aproveId from Prove authentication or verification, you list which partner-linked attributes exist (/v3/discover), then you retrieve the values you need (/v3/fetch). You do not need a bespoke integration to every partner for every flow; you integrate Prove’s APIs and let discover → fetch reflect what is in scope for that identity.
- Identity at the center — Discover and fetch are always scoped to a
proveIdfrom successful Prove authentication or verification. There is no anonymous “browse the marketplace”; the trust exchange starts from who Prove has already established for that session. - Consent built in — Fetch returns attribute values only when identity, program policy, and the consumer’s consent for that pull align with what Prove and the issuers enforce. Discover tells you what could be in play; fetch is where permitted data is actually released.
- Cryptographically bound — In product terms, each discover and fetch is mediated by Prove and scoped to the verified consumer behind the
proveId, using platform OAuth rather than ad hoc sharing of static identifiers or credentials with every issuer. That is how the exchange aims to turn authorization into a durable, identity-tied request and limit misuse, replay, or impersonation versus one-off pipes.
proveId; fetch only returns data the consumer has agreed to pull, under the same constraints as your upstream verification.
How ProveX fits together
These stages describe how the product is structured, not a single rigid checklist—your app may already haveproveId from an earlier session.
The sequence diagram shows that authentication or verification of the consumer must succeed and yield a proveId you use in API calls before /v3/discover. It also shows how discover answers whether partner-linked data exists for that identity, and how /v3/fetch follows when that data is available.
Establish identity (proveId)
ProveX assumes you have completed authentication and/or verification for the end user and persisted a proveId from a successful response. That identifier is Prove’s anchor for which consumer you are asking about in the marketplace layer.
Discover
Discover takes the consumer’sproveId and returns which attribute IDs and issuers exist for that identity—so you know whether partner-linked data is in play before you promise a UI or call fetch. You must call discover before fetch so you do not request attributes that do not exist.
Fetch
Fetch returns the attribute values for theattributeId values you selected from discover.
Discover and fetch surface partner-linked data Prove is allowed to return; they do not complete the partner’s UI or backend on your behalf. You are responsible for wiring
attributeValue into your integration with that issuer or partner.