Protocols and Formats

Each Data Push distribution combines two separate choices:

• Connection protocol - how Dronetag sends the data to your system.
• Output format - how each telemetry message is encoded.

Most formats are technically transport-independent, but not every combination is useful in practice. Choose the protocol based on how your system receives data, then choose a format that your target system can parse.

Recommended Combinations

Product / integration name	Recommended protocol	Recommended output format	Typical settings
Custom HTTP API or webhook	HTTP Webhooks	DUMP JSON, DUMP JSON Typed or a partner-specific socket format	Use an HTTPS target URL, HTTP Basic Authentication or OAuth 2.0 if required, and custom headers for API keys or tenant IDs.
Custom MQTT telemetry feed	MQTT Client	DUMP JSON, DUMP JSON Typed or a partner-specific socket format	Use MQTT over TLS when available, username/password authentication, QoS selected by your broker requirements, and {msgtype} in the topic if you want message-type routing.
Custom TCP socket feed	TCP Socket	DUMP JSON, DUMP JSON Typed or a partner-specific socket format	Use TLS or mTLS when crossing public networks. Enable embedded metadata only if your receiver expects the wrapper.
Custom UDP socket feed	UDP Socket	DUMP JSON or DUMP JSON Typed or a partner-specific socket format	Use only when packet loss is acceptable. Add AES payload encryption if the receiver supports it and the network path is not trusted.
TAK Server / CoT feed	TCP Socket	Cursor on Target XML	Use TCP mTLS when the TAK deployment requires client certificates.
SAPIENT feed	TCP Socket	SAPIENT	Set TCP protocol mode to sapient, configure heartbeat interval when required, and use TLS/mTLS if the receiving node requires certificate security.

Compatibility Matrix

Output format	HTTP Webhooks	MQTT Client	TCP Socket	UDP Socket	Notes
DUMP JSON	Recommended	Recommended	Supported	Supported	Best default for custom integrations.
DUMP JSON Typed	Recommended	Recommended	Supported	Supported	Same as DUMP JSON, with a $type field in the payload.
Cursor on Target XML	Possible	Not supported	Recommended	Possible	Used by TAK-compatible systems.
SAPIENT	Not supported	Not supported	Recommended	Not supported	Requires the SAPIENT TCP protocol mode.

Product Names

Some integrations are better known by the product or ecosystem name than by their protocol and format:

Protocol + format	Product / integration name
HTTP Webhooks + DUMP JSON	Custom webhook / custom API integration
MQTT + DUMP JSON	Custom MQTT integration
TCP or UDP + Cursor on Target XML	TAK Server integration
TCP + SAPIENT	SAPIENT integration

Portal Names and Security Options

The Integration Portal uses these connection labels:

Portal connection type	Compatible authentication choices	Transport and payload security
HTTP Webhooks	HTTP Basic Authentication, OAuth 2.0	HTTPS target URL
MQTT Client	HTTP Basic Authentication	MQTT over TLS, AES data encryption
TCP Socket	None	TLS/mTLS, AES data encryption
UDP Socket	None	AES data encryption

You can also leave authentication empty when your receiver does not require it. In this table, HTTPS, MQTT over TLS, and TLS/mTLS are transport security options, and AES data encryption is a payload encryption option, not a login method. The portal label HTTP Basic Authentication is also used for MQTT username/password credentials.

mTLS settings are shown in the portal only for TCP Socket distributions. The portal accepts either separate PEM files or PKCS#12 .p12 bundles:

• PEM: CA certificate, client certificate, client private key, and optional client key passphrase.
• PKCS#12: truststore .p12 with one or more certificates used to verify the server, and client .p12 with the client certificate and matching private key. Each bundle can have its own optional password. The portal converts both bundles to PEM before the integration uses them.
• Verify host checks the server hostname against the TLS certificate.

The selected Data Source controls which messages a distribution target may receive before protocol or format conversion. See Message Coverage for details about which message types each output format can send.

The portal also exposes delivery controls:

• Keep reliable controls behavior when messages cannot be delivered.
• Throttle messages limits how often Dronetag sends data to your receiver.
• Allow mixed content allows multiple message types in one request where the selected output format supports it.
• Send empty payloads sends an empty request at the throttle interval even when no new telemetry is available. It requires throttling to be enabled.

Common Setting Bundles

HTTP Webhooks API

Use this for custom APIs, webhooks, and most partner API integrations.

Typical settings:

• Target URL starts with https://.
• Authentication is HTTP Basic Authentication, OAuth 2.0, a partner-specific method, or custom HTTP headers.
• Additional headers can carry API keys, tenant identifiers, or environment selectors.

MQTT Client

Use this when your infrastructure expects telemetry on MQTT topics.

Typical settings:

• Target URI and port point to your MQTT broker.
• Transport is tcp or websockets, depending on your broker.
• Username/password authentication is configured when the broker requires it.
• Topic can include {msgtype} for DUMP JSON routing.
• QoS is usually 0 or 1, depending on whether low latency or delivery acknowledgement is more important.

TAK / CoT

Use this for TAK Server, ATAK, WinTAK, iTAK, or TAK-compatible middleware.

Typical settings:

• Output format is Cursor on Target XML.
• Protocol is usually TCP or UDP socket.
• TCP is preferred when you need connection state and better delivery behavior.
• UDP is common for simple CoT feeds where occasional packet loss is acceptable.
• mTLS can be enabled for TCP when your TAK Server requires client certificates.

SAPIENT

Use this only for systems that explicitly implement SAPIENT.

Typical settings:

• Protocol is TCP Socket.
• Output format is SAPIENT.
• TCP protocol mode is sapient.
• Heartbeat interval is configured when required by the receiving node.
• TLS or mTLS is enabled if required by the SAPIENT deployment.

Protocol Notes

HTTP Webhooks

HTTP is the best option when your system exposes an API endpoint. Dronetag sends POST requests to your target URL. The URL must start with http:// or https://.

Use plain HTTP only for development and testing. For production environments, HTTPS is strongly recommended.

HTTP can include metadata as headers, such as content type, message type, integration client ID, and public data visibility. You can also configure additional HTTP headers for your distribution.

Use HTTP for partner-specific API formats such as Altitude Angel, ASTRA, Highlander, and similar integrations.

MQTT Client

MQTT is the best option when your system already operates an MQTT broker and expects telemetry on topics. Dronetag connects as an MQTT client and publishes converted messages to the configured topic.

MQTT works well with JSON payloads. If you use DUMP JSON, you can include {msgtype} in the topic name to route UA telemetry, operator telemetry, system telemetry, and operation updates to separate topics.

TCP Socket

TCP is useful when the target system expects a persistent socket connection. It is also the recommended protocol for SAPIENT and one of the recommended protocols for TAK Server.

For SAPIENT, configure the TCP protocol mode as sapient. This enables the SAPIENT registration flow and length-prefixed binary messages.

TCP can also use TLS or mutual TLS when your target requires certificate-based security.

UDP Socket

UDP is useful for simple fire-and-forget delivery, especially when integrating with systems that already accept UDP feeds, such as some TAK deployments.

Because UDP does not provide delivery confirmation, use TCP or HTTP when your integration requires stronger delivery guarantees.

Metadata

HTTP sends metadata as request headers. MQTT, TCP, and UDP can optionally embed metadata into the payload for formats where that is useful.

Embedded metadata wraps the payload in an object with data and metadata fields. Use it only if your receiver is built to parse that wrapper.

When Unsure

For custom integrations, start with:

1. HTTP Webhooks + DUMP JSON if your service can expose an HTTPS endpoint.
2. MQTT + DUMP JSON if your infrastructure already uses MQTT.
3. TCP + Cursor on Target XML if you are integrating with TAK Server.
4. TCP + SAPIENT if your target system explicitly requires SAPIENT.