Onboard a new trading partner

Outcome

A new clearinghouse, state Medicaid MMIS, or commercial payer is registered in the gateway with its connection details, transport modes, capability matrix and credential, and the first end-to-end test transaction makes a clean round trip.

Prerequisites

Partner screens are gated by platform role, not by a per-screen scope:

Role	What it lets you do
PLATFORM_ADMIN	Create, edit and delete partners, set credentials, run Test connection
PLATFORM_SUPPORT, PLATFORM_READONLY	View the partner list and detail (the Customers and Enrollments tabs are hidden)

A signed trading-partner agreement with the counterparty in hand: the interchange identifiers both sides use, the connection details, and the submission window the partner expects.

What a trading partner record carries

Field	Notes
Name	Human label. Required.
Partner type	Clearinghouse, Payer, State or Other.
Partner code	Optional registry code. It is also the token the credential dialog asks you to type.
Protocol	SFTP, REST, AS2 or MFT. Decides which connection fields the dialog shows (see 2.2 — Connection types).
Transport modes	One or more of BATCH_SFTP, BATCH_REST, BATCH_AS2, REALTIME_REST. A routing rule whose dispatch mode is not in this list never resolves to the partner.
Capability matrix	Per transaction type, the transport modes the partner accepts (see 2.4 — Capabilities).
Credentials	Held in Azure Key Vault. The partner row carries secret names only.
Active	Checkbox in the dialog. The scheduled SFTP poll only lists active partners.

The dialog has no ISA field. The interchange identity on outbound files comes from the partner's envelope profile (SFTP partners, see 2.2), not from a per-partner ISA08 entry.

Steps

1. Open Configuration → Trading Partners (/trading-partners) in the EDI console and click New partner. The dialog asks for name, partner type, partner code, protocol, host, port and username, then the protocol's own fields, the transport modes, the capability matrix and Active.

2. Save. The partner record exists. Nothing routes to it until a routing rule picks it, and nothing authenticates until a credential is set.

3. Open the detail page at /trading-partners/:id. The page has these tabs:

   Tab	What you see here
   Overview	Partner code, type, protocol, status, created / updated, when the credential was last rotated and by whom, and a read-only capabilities summary.
   Connection	The whole stored connection config for the protocol, and Test connection → Run test.
   Credentials	One row per credential type with the vault secret name or Not set, and Set value / Rotate.
   Customers	Per-customer clearinghouse account bindings. PLATFORM_ADMIN only.
   Enrollments	The selected customer's Claim.MD enrollments. PLATFORM_ADMIN only.
   Feeds	Where each Claim.MD poll cursor has got to.
   Traffic	What has moved on each Claim.MD lane, and the request budget.
   Payers	Claim.MD's payer catalogue for the selected customer.
   Audit	Recent partner audit entries: when, actor, action, purpose, source IP.

   Every partner-row edit, including connection, transport modes, capabilities and Active, goes through Edit in the page header. The Overview and Connection tabs display what is stored; Connection adds Run test. Customers, Enrollments, Feeds, Traffic and Payers serve the Claim.MD lane and carry their own actions.

4. Check the connection on the Connection tab. To change it, use Edit. The fields depend on protocol; see 2.2 — Connection types.

5. Set the credential on the Credentials tab. It is write-only; the UI never shows the value. See 2.3 — Credential vault & rotation.

6. Set transport modes and the capability matrix in Edit, to match the partner agreement. See 2.4 — Capabilities.

7. Activate the partner with the Active checkbox in Edit.

8. Test the connection (see 2.5 — Probe & test connection).

9. Submit a test transaction. The exact flow depends on transaction type. See the relevant transaction-category chapter (Claims, Eligibility, Authorizations, Remittance).

Routing implications

Adding a partner does not by itself route any traffic to it. You must add a submission routing rule that picks this partner for some combination of payer / program / transaction (see Submission routing rules under Claims). Until then, the partner record exists but receives no outbound traffic.

Validation

Check	Expected
Partner appears on /trading-partners	Yes.
Test connection → Run test reports Connection healthy	Yes.
First test transaction completes the full round trip (outbound + ack chain)	Yes — tracked under /transactions filtered to this partner.
The Audit tab carries a WRITE row with purpose trading_partner.create	Yes.

Troubleshooting

Symptom	Cause	Fix
Probe fails with auth error	Wrong credentials	Rotate via Credentials tab.
Probe succeeds but outbound stalls	No routing rule picks this partner	Add one under Configuration → Routing Rules.
First test acknowledged but STC01 = A8:nnn (relational error)	Identifiers in the test envelope mismatch what the partner expects	Confirm ISA06/ISA08 and submitter NPI match the agreement.
Test rejected with TA104 = R and TA105 = 003	Sender/receiver not authorized at the partner	The partner's intake team has not registered our ISA06 yet. Escalate to them.

Next

2.2 — Connection types