Probe & test connection

Outcome

Before any production traffic flows to a partner, you have a clean probe result that confirms the transport, credentials, and basic identifier agreement work end to end — and you have a runnable health check you can re-trigger any time the partner reports an issue.

Prerequisites

A partner record with connection, credentials, and at least one capability set (2.1 through 2.4).

What Test connection does

The probe depends on the partner's Protocol, not its transport modes:

• SFTP resolves the private key first, else the password, applies the host-key pin if one is set, and lists the partner's Remote path (default /). It does not list the declared inbound or outbound directories, so a green probe does not prove them; the first poll does.
• REST calls the health path from the partner's REST config. With no health path configured it reports healthy without a network call.
• Every probe is bounded at 10 seconds and never sends a transaction.

Running a probe requires PLATFORM_ADMIN, and each run writes an audit row (purpose trading_partner.test_connection.ok or .fail).

Steps

1. Open the partner detail → Connection tab → Test connection → Run test.

2. Read the result. The panel shows Connection healthy with the latency, or Connection failed with the reason and details:

   Reason	Meaning
   (none), healthy	The probe completed.
   MISSING_CONFIG	Host or username is blank (SFTP), or the REST / MFT config is missing or malformed.
   MISSING_CREDENTIAL	No credential is recorded for the partner, or the vault has no secret by the recorded name.
   NOT_IMPLEMENTED	The protocol is not probed (AS2).
   (none), failed	The login, listing or health call failed. The details carry the transport's message, or timed out after 10000ms.

3. Re-run the probe any time. It does not send or read claim files.

There is no scheduled probe. The console runs a probe only when you click Run test.

Steps to run an end-to-end test transaction

Test connection confirms the connection; an end-to-end test confirms the partner accepts our actual EDI shape:

1. Pick the simplest transaction type the partner supports. Most forgiving: real-time 270. Most informative for batch partners: a single-claim 837P with ISA15 = T (test envelope).

2. Submit through the normal path but with usageIndicator = T. The gateway honors the test indicator end-to-end — the partner returns acks and (for 270) a 271 with no real PHI lookup.

3. Open /transactions filtered to this partner. The test submission appears with the test indicator visible.

4. Open the transaction's Raw Payload tab to confirm the envelope, names, and qualifiers all render as expected.

5. Watch for the ack chain — 999, 277CA (for claims), 271 (for eligibility). All should arrive within the partner's published SLA.

Validation

Check	Expected
Run test reports Connection healthy	Yes.
Test envelope (ISA15 = T) does not produce a member-charging adjudication	Yes — payers respect test envelopes.

Troubleshooting

Symptom	Cause	Fix
Probe succeeds but real transactions fail	Capability mismatch or routing rule mis-targets a different partner	Confirm capability set (2.4) and routing rules.
Probe sometimes fails, sometimes passes	Partner load-balancer routes to a stale backend	Open a ticket with the partner.
Probe always passes, real transactions always 999-rejected	Companion guide issue, not connection issue	Open the live preview on the bound guide; confirm the rules produce valid output.
Real-time probe fails with TLS error	Partner rotated their certificate	Refresh the trust store; if AS2, also refresh the partner certificate field.

Next

End of Trading Partners. The Eligibility section starts with 270 outbound — composing a request.