One way to access telemetry data from Dronetag devices is by letting our servers initiate the connection and push the data to yours. You can manage these connections through our Integration Portal, where you can configure everything yourself. This portal gives you full control over the integration settings, allowing you to select connection protocols like HTTP webhooks, MQTT, TCP, or UDP. You can for example easily switch between your testing and production environments and adjust other settings as needed.
To set up Data Push integration, you'll need access to the portal, which is available for users subscribed to our Pro plan or for business partners participating in our cooperative projects. If you're interested in gaining access, reach out to us.
Access the portal at https://integrations.dronetag.app.
The user-friendly web interface makes it simple to configure your integration in just a few steps.
Our integration framework is designed to be highly flexible, allowing you to customize many parameters for each integration without needing our help. Here’s what you can configure:
To start transferring data, you'll need to create a distribution target. This represents the service where you want to send your data. You can create multiple targets, but there is a limit. Once a target is created, our system will automatically distribute data until you deactivate or remove it.
To temporarily stop the data from being sent to your services, you can pause the distribution by marking it as inactive. If you no longer need the distribution, you can permanently delete it.
Each Data Push distribution combines two separate choices:
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.
| 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. |
| 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. |
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 |
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:
.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.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:
Use this for custom APIs, webhooks, and most partner API integrations.
Typical settings:
https://.Use this when your infrastructure expects telemetry on MQTT topics.
Typical settings:
tcp or websockets, depending on your broker.{msgtype} for DUMP JSON routing.0 or 1, depending on whether low latency or delivery acknowledgement is more important.Use this for TAK Server, ATAK, WinTAK, iTAK, or TAK-compatible middleware.
Typical settings:
Use this only for systems that explicitly implement SAPIENT.
Typical settings:
sapient.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 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 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 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.
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.
For custom integrations, start with:
While configuring your integration distribution in our integration portal, you will encounter the field "data source". This article provides a detailed explanation of what data sources are and how they can be utilized in your integration.
The data source controls which messages are eligible for a distribution target. The selected output format can further limit which eligible message types are actually sent. See Message Coverage for details.
Requirements: None
Data shared: Only the data associated with the distribution owner account
This data source is available to anyone using the integration portal. It is primarily intended for initial testing and evaluation. When selected, it provides access only to the data associated with the same account as the account creating the distribution (owner). Only devices registered to this account are visible, ensuring privacy and isolation from other users' data.
Requirements: Existing device group related to an order of Dronetag devices
Data shared: All data, regardless of privacy settings or registration status
Device Group is intended for customers who have entered into a partnership with Dronetag and have purchased a group of devices. These devices are assigned to a pre-defined static group, which can be selected as a data source. The group membership is fixed and can only be changed upon request. Device groups are not visible or accessible to regular Dronetag users.
Requirements: Partnership registration with Dronetag
Data shared: Opt-in by users, all data regardless of privacy settings
Partner Integrations are visible and accessible to users, who have full control over which integrations can access their data.
Users can allow or deny access to their data for each integration via the Dronetag App, in the "Integrations" section. This means that users can choose to share their data with specific integrations while keeping it private from others.
Partner Integrations can be configured to prompt users for an arbitrary token, identifier, or authorization value when enabling the integration in the Dronetag App. This allows users to enter credentials or identifiers required by the third-party service, which can reliably associate Dronetag users with their own user accounts or authorization systems.
The partner integration approach increases transparency and user awareness, allowing users to remain in private mode while still enabling third-party integrations. This is the recommended approach for most integrations.
Each partner integration requires the following information to be provided, which is then displayed in the Dronetag App 'Integrations' section: