Federation Help

Federation lets devices on one network exchange Cursor-on-Target (CoT) traffic and shared files with devices on another network. supports three kinds of federation. They share the same on/off controls, but differ in who you're peering with and how the connection is set up.

Within an organization

From a network's Federated Networks tab, click Federate and pick another network in the same organization. Federation goes into effect immediately — no invite code is needed, because both networks share the same owner.

This is the simplest way to "stack" networks together. For example, you can federate a 50-device network with a 25-device network and devices on either side will see each other, subject to the direction toggles below.

Across organizations

To federate with a network owned by another organization, you exchange a short federation code:

  1. The other organization opens their network's Federated Networks tab and clicks Generate Code. They send you the 8-character code.
  2. On your network's Federated Networks tab, click Federate, paste the code, and choose your direction and data-package settings.
  3. Once accepted, both sides can independently edit their own end of the federation (their toggles only affect what they send and accept) or stop federating at any time.

Codes are single-purpose: clicking Generate Code issues a fresh one and invalidates any previous code, and Clear Code revokes the active code without affecting federations that have already been accepted.

With an external TAK Server

External TAK Server federation lets a self-hosted or third-party TAK Server (one that isn't on ) peer with one of your networks. It uses the standard TAK Server v2 federation protocol over TLS, so the remote side just needs a recent TAK Server.

The setup is on the network's External TAK Servers tab. The flow has two halves — what we publish, and what they register.

What we publish

Expand Connection info for remote TAK Server peers on the tab to see the information the remote admin needs:

  • Hostname, port, and the SHA-256 fingerprint of our federation certificate.
  • Our federation certificate (.pem) and CA certificate (.pem), downloadable as files. The remote admin imports the CA cert into their federation truststore so the TLS handshake succeeds.
  • Two ready-to-paste CoreConfig.xml snippets — an outgoing connection block and a federate-routing block — that the remote admin drops into their TAK Server's <federation> element.

What they register

The remote admin sends back the SHA-256 fingerprint of their federation client certificate. You click Add peer, paste the fingerprint and a display name, and pick the direction and data-package options. Until you do, the peer's TLS handshake against us will be rejected.

Live status

Once a peer is registered, the table on the same tab shows whether the connection is up, inbound and outbound CoT events per second, and when we last heard from them. Each peer's direction and data-package settings are visible as In, Out, DP-In, and DP-Out chips.

Deployment configuration

External TAK Server federation depends on deployment-wide settings the operator configures in appsettings.json under Federation. If any required field is missing, the External TAK Servers tab will tell you which keys to set. The two that always need a real value are:

  • Federation:AdvertisedHostname — the externally-resolvable hostname remote TAK Servers dial (e.g. tak.example.com).
  • Federation:OurFederateId — a stable identifier unique to this deployment, stamped into federation provenance.

Reference: TAK Server federation docs.

Direction and data-package options

All three federation kinds use the same four toggles. Each side controls its own toggles independently — for example, a peer can send you traffic without you sending any back.

  • Incoming (chip label: In) — accept CoT messages from the peer. With this off, the peer's traffic is dropped at our edge.
  • Outgoing (chip label: Out) — send our network's CoT messages to the peer. With this off, our devices' positions and chats are not shared.
  • Accept Data Packages (chip label: DP-In) — receive shared data packages (mission files, imagery, attachments) from the peer.
  • Share Data Packages (chip label: DP-Out) — let the peer download data packages from our side.

Setting both Incoming and Outgoing off effectively pauses federation without removing the relationship. Use this when you want to keep the peer registered (and its certificate trusted) but temporarily stop traffic.

Data-package toggles are independent of the CoT toggles. You can federate live CoT in both directions while keeping data packages one-way (or off entirely), which is common when one side is treated as the authoritative source of mission files.

Permissions

Federation actions are gated by per-team permissions. A user must be in a team with the relevant permission granted on the network they're configuring.

  • Federate within organization — start federations between two networks of the same organization.
  • Federate with other organizations — generate / clear federation codes, redeem codes from other organizations, and add or remove external TAK Server peers.
  • Change federation — edit the direction and data-package toggles on an existing federation or external peer.
  • Stop federating — remove a federation relationship or external peer.

Users without these permissions can still see the Federated Networks and External TAK Servers tabs (so federation status stays visible to operators), but the action buttons are hidden.

Plan availability

Federating two networks owned by the same account (within an organization, or across organizations you control) is available on the paid plans. The Free plan does not federate.

Each registered external TAK Server peer counts toward your token usage.

privacy policy | Terms of service
An unhandled error has occurred. Reload 🗙