Automation for the proof workflow
The API is for teams that need the same proof workflow inside an ERP, internal tool, marketplace, PSP, GRC system, or reconciliation process.
It should not be treated as a generic rates API. Reference rates are inputs. The important output is reusable proof evidence with document id, payload hash, source attribution, and verification.
Integration flow
The public API model is dataset-first so web and API users work from the same source/product/periodicity vocabulary.
- Discover valid datasets from the catalog.
- Retrieve reference-rate data when the workflow needs it.
- Open or reuse proof bundles for supported source/date combinations.
- Download ready proof documents after readiness checks pass.
- Verify proof document metadata by document id and payload hash.
Why compliance reviewers care
A technical integration is only useful if the evidence can still be reviewed by a human. FXProof keeps the proof document and public verification path visible outside the API response.
Read the docs
Use the interactive docs, OpenAPI, and Postman artifacts to inspect available endpoints and request shapes.
Read API docsCheck a proof
Keep public verification available for reviewers who receive a proof document outside your integration.
Verify a PDFStart from datasets
Use catalog discovery instead of guessing source/product/periodicity combinations.
View sourcesQuestions
Is FXProof API-first?
No. API access is an optional automation path. The primary product is signed/verifiable proof documents and proof bundles.
How should an integration discover valid data?
Use dataset-first discovery from the catalog. Do not guess source/product/periodicity combinations.