Skip to main content
A public provider implements the provider contract. Publishing its profile is a separate step: it lets venues discover the integration and read its connection instructions. Publication does not grant execution approval, liquidity access or trader accounts. A venue’s Get listed application controls its tile in trader Connect and is a different listing.

​
Browse and connect

Open Providers → Browse providers in sandbox Back Office. Select an integration to see its canonical company name and logo, description, maintainer, supported capabilities, documentation, support email and connection requirements.
  1. Contact the provider if it requires a commercial agreement or a dedicated connection.
  2. Select Add pinned release to venue. This creates a candidate registration containing that immutable manifest and its published release ID. It does not contact the provider.
  3. Use the existing Connections form to save your private endpoint and credentials.
  4. Run its validation. Account discovery, bindings and execution qualification remain separate from listing and manifest validation.
The built-in section is informational and includes the current listing state. Trader-only built-ins are labeled Trader Connect only. Unlisted or disabled entries grant no connection permission. Their presence in the directory does not make them venue execution destinations. For FXCubic, the current integration is test-market quotes only, maintained by TRDRS. Dedicated vendor credentials and a provisioned connection are required; another venue cannot borrow Meridian’s credentials or connection.

​
Develop and publish

You can use the same Venue API without installing Back Office. Venue-key requests use /api/partner/venues/{venueId}/provider-catalog; signed-in Back Office requests use the matching /api/operator/venues/{venueId}/provider-catalog routes. The venue must match the deployment and key environment. Reads require venue membership or venue:read; publishing writes require the maintaining organization owner and provider:manage. Every write needs Idempotency-Key.
  1. Create provider profile creates a private canonical company brand. Add the name, description, documentation URL, connection guide URL, support email, asset classes, connection requirements and an honest maintainer note. Upload the logo through the profile’s logo action; the engine sanitizes it into the existing company logo store.
  2. Record release stores the tested manifest, its digest, author and evidence link permanently. Data-only releases require evidence named provider-market-data-v1. Execution releases require the complete provider-contract-v1 suite, with no skipped rules counted as passes.
  3. Preview in sandbox makes the release visible only to members of its maintaining organization. It needs no production listing approval.
  4. Submit for public review queues the release for TRDRS review. An evidence URL alone is not approval. The reviewer checks its capability and environment claims and records a decision.
  5. A reviewed release appears publicly for its stated environment. Installing it still creates a candidate, not an execution-qualified connection.
Profile and logo changes increment expectedVersion and hide the profile until a new release is reviewed. A stale version refuses with version_conflict. An identical request and retry key returns the original result; a different request under that key refuses with idempotency_conflict. Withdrawing or suspending a listing hides it from discovery and future installation; it does not disconnect customers or rewrite pinned manifests.

​
Routes

The OpenAPI reference contains the complete request shapes and refusal responses. This extends the existing registration and connection routes; private endpoints and credentials are never directory fields.

​
Hand maintenance to the provider’s team

The source and target need existing organizations and verified owners. This is an ownership change, so it requires human owner sessions, not a venue key held by a CRM.
  1. The source owner opens Hand off maintenance and proposes the target organization ID.
  2. A different verified owner of that target organization accepts the incoming handoff within seven days. The source can cancel a pending handoff, including one that has expired.
  3. The target gains profile/release maintenance. The source loses ongoing edit authority.
The operator-only routes are POST /profiles/{companyId}/transfer with targetOrganizationId and expectedVersion, and POST /transfers/{transferId}/accept or /cancel with an empty body. All use the operator prefix above and a retry key. An unchanged proposal is required at acceptance; changed profiles or expired proposals refuse. Company and release IDs, original release authors and customer connections stay intact. Customer credentials do not transfer with the public profile. Source-code repository access, deployment secrets and vendor contracts must be handed over separately; accepting the profile is not proof that those external steps happened. Public review is first-party administration: the operator-only POST /releases/{releaseId}/review requires a verified ADMIN_EMAILS session and sends decision (list, changes_requested, suspend), note and expectedVersion. A venue owner or venue key cannot approve its own listing merely by owning the profile.