Protocols and formats | Dronetag Help (https://help.dronetag.com/developers/data-push/protocols-and-formats)
citeturn10view0 [wordlim: 200] Crawled: 2 days ago; Content type: text/html; Source: open({"ref_id":"https://help.dronetag.com/developers/data-push/protocols-and-formats","lineno":null}); Redirected to URL: https://help.dronetag.com/developers/data-push/protocols-and-formats/; Total lines: 220
L0: cite0†Skip to main content L1: 
L2:   * cite1†Dronetag Scout L3:   * cite2†Dronetag Mini 4G L4:   * cite3†Dronetag RIDER L5:   * cite4†Dronetag BS gen.2 L6:   * cite5†Dronetag Beacon gen.2 L7:   * cite6†Dronetag Mini L8:   * cite7†Dronetag Beacon L9:   * cite8†Dronetag BS L10:   * cite9†Dronetag DRI L11: 
L12:   * Developers
L13: 
L14:   * cite10†Introduction L15:   * How to integrate
L16: 
L17:     * cite11†Getting started L18:     * cite12†Integrate Using the API L19:     * cite13†Integrate Using InterUSS L20:     * cite14†Direct Hardware Integration L21:   * Pulling from our API
L22:     * cite15†Getting Started with the REST API L23:     * cite16†Getting Started with Socket.io L24:     * cite17†Authenticating API Requests L25:   * Pushing to your API
L26: 
L27:     * cite18†Getting started L28:     * cite19†Protocols and formats L29:     * cite20†Data Sources Explained L30:     * cite21†Distribution types L31: 
L32:     * cite22†Message Coverage L33:     * cite23†Monitoring Your Distribution L34:     * cite24†Troubleshooting L35:   * Guides
L36:     * cite25†Choosing the Right Integration Method L37:     * cite26†Accessing Historical Telemetry L38:     * cite27†Accessing Real-Time Telemetry L39:     * cite28†Accessing Real-Time Device Status L40:     * cite29†Setting up TAK Server Integration L41:     * cite30†Understanding Altitude Values L42:     * cite31†Understanding DUMP Messages L43:     * cite32†Using Simulated Data L44:   * Migration Guides
L45: 
L46:     * cite33†Transition to Region-Based Telemetry Retrieval L47:     * cite34†Updating Your Authentication Method L48: 
L49: [Button: On this page]
L50: # Protocols and Formats
L51: 
L52: Each Data Push distribution combines two separate choices:
L53: 
L54:   * Connection protocol - how Dronetag sends the data to your system.
L55:   * Output format - how each telemetry message is encoded.
L56: 
L57: 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.
L58: ## Recommended Combinationscite35†​ L59: Product / integration name  | Recommended protocol  | Recommended output format  | Typical settings
L60: --- | --- | --- | ---
L61: 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.
L62: 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.
L63: 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.
L64: 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.
L65: TAK Server / CoT feed  | TCP Socket  | Cursor on Target XML  | Use TCP mTLS when the TAK deployment requires client certificates.
L66: 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.
L67: ## Compatibility Matrixcite36†​ L68: Output format  | HTTP Webhooks  | MQTT Client  | TCP Socket  | UDP Socket  | Notes
L69: --- | --- | --- | --- | --- | ---
L70: DUMP JSON  | Recommended  | Recommended  | Supported  | Supported  | Best default for custom integrations.
L71: DUMP JSON Typed  | Recommended  | Recommended  | Supported  | Supported  | Same as DUMP JSON, with a `$type` field in the payload.
L72: Cursor on Target XML  | Possible  | Not supported  | Recommended  | Possible  | Used by TAK-compatible systems.
L73: SAPIENT  | Not supported  | Not supported  | Recommended  | Not supported  | Requires the SAPIENT TCP protocol mode.
L74: ## Product Namescite37†​ L75: 
L76: Some integrations are better known by the product or ecosystem name than by their protocol and format:
L77: 
L78: Protocol + format  | Product / integration name
L79: --- | ---
L80: HTTP Webhooks + DUMP JSON  | Custom webhook / custom API integration
L81: MQTT + DUMP JSON  | Custom MQTT integration
L82: TCP or UDP + Cursor on Target XML  | TAK Server integration
L83: TCP + SAPIENT  | SAPIENT integration
L84: ## Portal Names and Security Optionscite38†​ L85: 
L86: The Integration Portal uses these connection labels:
L87: 
L88: Portal connection type  | Compatible authentication choices  | Transport and payload security
L89: --- | --- | ---
L90: HTTP Webhooks  | HTTP Basic Authentication, OAuth 2.0  | HTTPS target URL
L91: MQTT Client  | HTTP Basic Authentication  | MQTT over TLS, AES data encryption
L92: TCP Socket  | None  | TLS/mTLS, AES data encryption
L93: UDP Socket  | None  | AES data encryption
L94: 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.
L95: 
L96: mTLS settings are shown in the portal only for TCP Socket distributions. The portal accepts either separate PEM files or PKCS#12 `.p12` bundles:
L97:   * PEM: CA certificate, client certificate, client private key, and optional client key passphrase.
L98:   * 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.
L99:   * Verify host checks the server hostname against the TLS certificate.
L100: The selected Data Source controls which messages a distribution target may receive before protocol or format conversion. See cite22†Message Coverage for details about which message types each output format can send.
L101: 
L102: The portal also exposes delivery controls:
L103:   * Keep reliable controls behavior when messages cannot be delivered.
L104:   * Throttle messages limits how often Dronetag sends data to your receiver.
L105:   * Allow mixed content allows multiple message types in one request where the selected output format supports it.
L106:   * Send empty payloads sends an empty request at the throttle interval even when no new telemetry is available. It requires throttling to be enabled.
L107: ## Common Setting Bundlescite39†​ L108: 
L109: ### HTTP Webhooks APIcite40†​ L110: 
L111: Use this for custom APIs, webhooks, and most partner API integrations.
L112: 
L113: Typical settings:
L114: 
L115:   * Target URL starts with `https://`.
L116:   * Authentication is HTTP Basic Authentication, OAuth 2.0, a partner-specific method, or custom HTTP headers.
L117:   * Additional headers can carry API keys, tenant identifiers, or environment selectors.
L118: ### MQTT Clientcite41†​ L119: 
L120: Use this when your infrastructure expects telemetry on MQTT topics.
L121: 
L122: Typical settings:
L123: 
L124:   * Target URI and port point to your MQTT broker.
L125:   * Transport is `tcp` or `websockets`, depending on your broker.
L126:   * Username/password authentication is configured when the broker requires it.
L127:   * Topic can include `{msgtype}` for DUMP JSON routing.
L128:   * QoS is usually `0` or `1`, depending on whether low latency or delivery acknowledgement is more important.
L129: ### TAK / CoTcite42†​ L130: 
L131: Use this for TAK Server, ATAK, WinTAK, iTAK, or TAK-compatible middleware.
L132: 
L133: Typical settings:
L134: 
L135:   * Output format is Cursor on Target XML.
L136:   * Protocol is usually TCP or UDP socket.
L137:   * TCP is preferred when you need connection state and better delivery behavior.
L138:   * UDP is common for simple CoT feeds where occasional packet loss is acceptable.
L139:   * mTLS can be enabled for TCP when your TAK Server requires client certificates.
L140: ### SAPIENTcite43†​ L141: 
L142: Use this only for systems that explicitly implement SAPIENT.
L143: 
L144: Typical settings:
L145: 
L146:   * Protocol is TCP Socket.
L147:   * Output format is SAPIENT.
L148:   * TCP protocol mode is `sapient`.
L149:   * Heartbeat interval is configured when required by the receiving node.
L150:   * TLS or mTLS is enabled if required by the SAPIENT deployment.
L151: 
L152: ## Protocol Notescite44†​ L153: ### HTTP Webhookscite45†​ L154: 
L155: 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://`.
L156: 
L157: Use plain HTTP only for development and testing. For production environments, HTTPS is strongly recommended.
L158: 
L159: 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.
L160: Use HTTP for partner-specific API formats such as Altitude Angel, ASTRA, Highlander, and similar integrations.
L161: ### MQTT Clientcite46†​ L162: 
L163: 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.
L164: 
L165: 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.
L166: ### TCP Socketcite47†​ L167: 
L168: 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.
L169: 
L170: For SAPIENT, configure the TCP protocol mode as `sapient`. This enables the SAPIENT registration flow and length-prefixed binary messages.
L171: 
L172: TCP can also use TLS or mutual TLS when your target requires certificate-based security.
L173: ### UDP Socketcite48†​ L174: 
L175: UDP is useful for simple fire-and-forget delivery, especially when integrating with systems that already accept UDP feeds, such as some TAK deployments.
L176: 
L177: Because UDP does not provide delivery confirmation, use TCP or HTTP when your integration requires stronger delivery guarantees.
L178: ## Metadatacite49†​ L179: 
L180: HTTP sends metadata as request headers. MQTT, TCP, and UDP can optionally embed metadata into the payload for formats where that is useful.
L181: 
L182: 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.
L183: ## When Unsurecite50†​ L184: 
L185: For custom integrations, start with:
L186: 
L187:   1. HTTP Webhooks + DUMP JSON if your service can expose an HTTPS endpoint.
L188:   2. MQTT + DUMP JSON if your infrastructure already uses MQTT.
L189:   3. TCP + Cursor on Target XML if you are integrating with TAK Server.
L190:   4. TCP + SAPIENT if your target system explicitly requires SAPIENT.
L191: 
L192: cite18†Previous Getting started cite20†Next Data Sources Explained L193:   * cite35†Recommended Combinations L194:   * cite36†Compatibility Matrix L195:   * cite37†Product Names L196:   * cite38†Portal Names and Security Options L197:   * cite39†Common Setting Bundles L198:     * cite40†HTTP Webhooks API L199:     * cite41†MQTT Client L200:     * cite42†TAK / CoT L201:     * cite43†SAPIENT L202:   * cite44†Protocol Notes L203:     * cite45†HTTP Webhooks L204:     * cite46†MQTT Client L205:     * cite47†TCP Socket L206:     * cite48†UDP Socket L207:   * cite49†Metadata L208:   * cite50†When Unsure L209: 
L210: Find more
L211: 
L212:   * cite51†Dronetag Web App†dronetag.app L213:   * cite52†Dronetag Website†dronetag.com L214: 
L215: Help
L216:   * cite53†Troubleshooting guide L217:   * help@dronetag.cz
L218: 
L219: Copyright © 2026 Dronetag s.r.o.
