> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trdrs.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish a provider integration

> Publish a discoverable provider profile, keep customer connections private, and safely hand maintenance to another team.

A public provider implements the [provider contract](/providers/provider-self-check). 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](/guides/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](https://sandbox.trdrs.co/developer).
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

| Method | Relative path | Purpose |
| - | - | - |
| GET | `/directory?after={cursor}` | Public profiles and owned sandbox previews; follow `nextCursor`. |
| GET | `/mine` | Maintained profiles, releases and incoming/outgoing handoffs. |
| POST | `/profiles` | Create a private profile with a `profile` object. |
| POST | `/profiles/{companyId}` | Update `profile` with `expectedVersion`. |
| POST | `/profiles/{companyId}/logo` | Upload base64 `data` with `expectedVersion`. |
| POST | `/profiles/{companyId}/releases` | Record `manifest`, `evidence` and `expectedVersion`. |
| POST | `/profiles/{companyId}/publication` | Send `releaseId`, `action` (`preview`, `submit`, `withdraw`) and `expectedVersion`. |
| POST | `/releases/{releaseId}/install` | Pin an eligible release with an empty body. |

The [OpenAPI reference](https://trdrsco-engine-sandbox.fly.dev/docs/openapi.json) 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.