The gateway connector

The Gateway Connector plugin adds two new connector types to your Mirth channels: a Gateway Listener (source) and a Gateway Sender (destination). Together they are what actually sends and receives data through the tunnels provisioned by the Contact System.

Gateway Listener (source connector)

A Gateway Listener is the receiving side of a P2P connection. It accepts incoming data from one or more authorized peers — any peer that has been granted access can deliver to the same listener.

Published Endpoint status

The Listener settings panel does not ask you to pick or create a channel. When you deploy a channel that has a Gateway Listener, the Contact System automatically publishes it as a Published Endpoint — a one-to-one projection of this Mirth channel that the plugin keeps in sync. The panel shows a read-only Published Endpoint status line reflecting that endpoint’s current cloud state (for example, published or appears as a Published Endpoint when this channel is deployed before the first deploy).

Authorizing peers

To accept incoming data, select Cloud-managed peers in the panel. The listener then accepts the set of peers your organization has approved in the Contact System dashboard. There is no local peers table, no Add Peer button, and no per-peer toggle — you add, pause, and revoke peers from the cloud dashboard under Connections, and the plugin keeps the listener in sync.

Note

You never enter a shared secret here. Each authorized peer’s secret is fetched automatically when the connector starts, using the server’s own credential, and is held only in memory — it is never typed into the panel or saved to the channel. (Manual token entry applies only to the separate admin connection feature, which uses a one-time server registration token.)

Advanced settings

Collapsed by default, Advanced Settings exposes the connectivity service addresses and the certificate paths used to secure the tunnel, shared across all peers on this listener. You can also set the maximum concurrent connections and a receive timeout here. These values are filled in for you from the platform’s defaults; you normally only change them in self-hosted or test setups.

Gateway Sender (destination connector)

A Gateway Sender delivers data to one specific remote peer. It is always 1:1 — to fan out to multiple peers, add multiple destination connectors on the same channel.

Binding to a remote listener

The sender panel has a single picker, labelled Bind to: inside the Remote Listener box. It lists the granted connections where this server is the sending side. Choose one to bind the destination to that remote listener one-to-one; the panel then auto-fills the remote address and signaling details. Use Unbind to clear the binding and choose a different connection.

There is no separate channel picker on the sender — only listeners are published to the cloud — and there is no shared-secret field. As on the listener side, the secret is fetched automatically when the connector starts.

Standard tier required

The gateway connectors are gated by your server’s subscription tier. On a free-tier server the connector is read-only — every field is disabled and the panel shows a Standard tier required notice with an Upgrade link. This is a runtime entitlement, not a build option: upgrading the server’s plan unlocks the connector with no reinstall. See tiers.

Connection mode

In Advanced Settings, choose how the tunnel reaches the remote peer:

• NAT traversal (default) — the two servers negotiate a direct peer-to-peer path through the platform’s connectivity services. No inbound firewall ports are required, which makes this the right choice for most networks.
• Direct — a direct, mutually authenticated network connection. Both sides need a network address the other can reach; useful in controlled environments where a direct path already exists.

How listeners and senders stay linked

You don’t manage routing identities by hand — the platform derives them from your Mirth channels:

• A Gateway Listener is identified by its own Mirth channel. Every authorized peer delivers to that one listener, which is why a single listener can accept data from many peers at once.
• A Gateway Sender delivers to the remote listener named by the connection you bound it to.

When you deploy a channel that has a Gateway Listener, the plugin publishes and keeps the matching Published Endpoint in sync automatically. There is nothing to re-link.

Note

If you replace or re-create a Mirth channel, it is published as a new endpoint. Re-grant access to the new channel in the Contact System; you do not relink anything inside the connector panel.