Manage trading partner credentials

Outcome

Each trading partner you exchange EDI with has a registered profile, current credentials in the vault, and a routing rule that picks it for the right claims. Credentials never appear in the UI as plaintext — rotation flows through a write-only vault.

Prerequisites

Scope	What it lets you do
edi.partners.read	View partners and routing rules
edi.partners.write	Add / edit partners; rotate credentials; edit routing

A registered payer with at least one program (see 5.1 — Payers, programs & contracts) — partners route based on payer + program.

What is a trading partner

A trading partner is the EDI counterparty — a clearinghouse, a state Medicaid MMIS, a commercial payer that accepts direct submissions, or any other entity you exchange X12 files with.

Each partner carries:

Field	Meaning
Name	Display label.
ISA08	The interchange receiver ID we put on outbound files.
Connection type	SFTP, AS2, REAL_TIME (HTTP).
Capabilities	Which transactions this partner accepts: 837P, 837I, 270, 278, 835 (inbound), 277CA (inbound), 999 (inbound).
Companion guides	Per-state or per-payer rule overlays this partner enforces.
Credentials	Held in the vault. The UI shows last-rotated dates; the secrets themselves are never displayed.

Steps

1. Pick Configuration → EDI → Trading Partners to land on the list. Each row shows partner name, connection type, capabilities, and credential status (fresh / aging / expired).

2. Click + New partner to register one, or open an existing partner. The form asks for name, ISA08, connection type, and capabilities. The companion guide picker is on the Detail page, not the create form.

3. Set credentials with Set credentials on the Detail page. The dialog varies by connection type:

   Type	Secrets
   SFTP	Host, port, username, and one of password OR private-key.
   AS2	URL, our certificate, partner certificate.
   REAL_TIME	Endpoint URL, bearer token.

   Secrets are submitted to the vault directly — the UI never reflects them back. After save, the page shows Credentials set on YYYY-MM-DD by <user>.

4. Probe the connection with Test connection. The platform attempts a live connection (SFTP login + directory listing, AS2 ping, HTTP HEAD) and reports success / failure with the raw transport-level error if it fails.

5. Bind companion guides under the Companion Guides tab. Each guide has an effective window — the platform applies the latest active guide whose window covers the submission date.

6. Pick the partner from a routing rule under Configuration → Routing. A routing rule says "claims matching <conditions> go to this partner". Conditions can specify line of business, state, payer, program, or any combination. Most-specific match wins.

7. Rotate credentials when needed. Rotate credentials reopens the same dialog. The platform replaces the secret atomically — there is no window where the partner has neither old nor new in place.

Validation

Check	Expected
Partner appears in the list	Yes.
Test connection returns success	Yes.
Routing rule applies to a sample claim	Use the Precedence simulator on the routing list page.
Outbound 837 carries the partner's ISA08	Yes — confirmed in any submitted EDI envelope.

Troubleshooting

Symptom	Cause	Fix
Test connection fails with auth error	Wrong credentials or expired key	Rotate via Set credentials.
Outbound batch routed to the wrong partner	A more-specific routing rule exists	Use the Precedence simulator to see which rule fired; adjust the rule's conditions.
Companion guide not applied	Effective window does not include today	Activate a guide whose window covers the submission date, or extend the existing guide.
Save returns 409 on credential set	Concurrent rotate from another admin	Reopen the dialog and try again — the latest write wins; the audit log records both.

Next

5.7 — Manage SFTP feeds & Push API keys