Reference · Platform Procurement
Integration Evidence: Referenced, Tested and Certified
Distinguish integration references, documentation, demonstrations, tests and certification using a record of scope, issuer, environment, version and date.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
What is Integration evidence?
Integration evidence describes what has actually been established about two systems working together. A public reference, documented API, demonstration, recorded test and formal certification support different conclusions. Record the issuer, version, environment, tested operations and date. No label should imply capabilities or approvals beyond that evidence.
Ask what the evidence proves
A supplier logo or list entry establishes that an integration is referenced, not that the buyer's workflow has been tested. API documentation shows a defined interface, while an implementation can still map fields incorrectly or omit error handling. A video demonstration shows one observed path under conditions that may be unknown.
NIST's supplier guidance discusses several forms of assurance, including attestations, certifications and inspections. These are not interchangeable guarantees. If certification is claimed, identify the issuer, scheme, certified subject, validity and scope; do not invent an official certification merely because a vendor or integrator completed its own test.
Sources for this section
- NIST SP 1305: supplier requirements and responsibilitiesnvlpubs.nist.gov
Match the test to the intended operation
Record direction and business function: reading balances differs from creating accounts, submitting orders or posting payments. Identify API version, environment, authentication, permissions and dependencies. For example, cTrader documents a particular FIX interface; that specification does not prove that every CRM supports every cTrader operation.
A useful test record includes normal behavior, meaningful errors, duplicates, reconnects or other failure cases relevant to the operation. Use synthetic data in an authorized environment. Preserve the observed output and downstream state so a reviewer can tell whether success meant an accepted request, completed action or merely a reachable endpoint.
Sources for this section
- cTrader FIX API specificationhelp.ctrader.com
Keep technical evidence and commercial permission separate
A passing sandbox test does not establish production credentials, merchant eligibility, platform entitlement or the right to supply a service to a specific entity. Track those dependencies separately. Stripe's restricted-business policy, for example, prohibits funded prop trading and restricts certain financial services; an available connector cannot override that policy.
Give evidence a review trigger. An API change, new tenant, different account type or revised permission set can require retesting. Retain the old record as history, but show the current unresolved scope clearly. For current FxTrusts integration claims, use the published integration-status matrix rather than inferring support from this reference worksheet.
Sources for this section
Example: six hypothetical evidence records
These fictional records illustrate classification, not scores for real vendors. A higher-sounding label can still be irrelevant if it covers the wrong operation or version. Procurement should select evidence appropriate to its required workflow and identify the next check.
| Record | What is established | What remains open |
|---|---|---|
| Supplier logo list | Integration is referenced | Operations and test evidence |
| Publisher API specification | Interface is documented | Buyer implementation behavior |
| Recorded demo | Shown path worked once | Environment and failure cases |
| Signed staging test | Named cases passed in staging | Production conditions |
| Production acceptance record | Scoped deployment checks passed | Future version changes |
| Issuer-verified certification | Named scheme and scope confirmed | Capabilities outside that scope |
Implementation checklist
- Record source, issuer, environment, version, date and operation.
- Verify certification claims with the named issuer and actual scope.
- Separate functional testing from entitlement and merchant eligibility.
- Assign retest triggers and preserve unresolved dependencies.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- NIST SP 1305: supplier requirements and responsibilitiesnvlpubs.nist.gov
- cTrader FIX API specificationhelp.ctrader.com
- Stripe prohibited and restricted businessesstripe.com
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.