Welcome to the Developers section of the Dronetag Help Website.

This area is dedicated to providing you with the developer resources and technical guidance. Here, you can access detailed API documentation, which will help you establish connections with our Remote ID solutions.

In addition to the APIs, you'll find guidelines, best practices, and other supporting information that are essential for building reliable integrations. Whether you're working on connecting our products to your existing platforms or experimenting with new ideas, this section offers the tools and knowledge base to support your development efforts.

Dive in to explore how Dronetag can fit into your systems and unlock new possibilities.

Terms of Service​

Using our API is subject to our Terms of Service.

Dronetag provides several integration options to allow access to data from our devices, focusing primarily on Remote ID data. This guide will help you choose the most suitable method for integrating Dronetag into your systems, whether you are working with UTM platforms or building custom solutions.

I Want to Use Existing Integrations​

If you prefer to work with established platforms, Dronetag supports several ready-made integrations:

The integrations currently implemented by Dronetag include:

Data Push can also deliver Dronetag's own formats, including DUMP JSON, DUMP JSON Typed, and Dronetag Legacy JSON. These are useful when you are building a custom integration instead of connecting to one of the platforms listed above. See Protocols and Formats for recommended combinations.

I Want to Build My Own Integration​

For custom solutions or new integrations, we provide multiple options for building the integrations:

If you're unsure which integration method is right for you, check out our guide on Choosing the Right Integration Method for more information and guidance.

Integrating via our API provides a straightforward way to exchange information programmatically with third-party systems or services. We offer two primary methods to facilitate this integration.

Pull Data from Our API​

By pulling data from our API, you can easily retrieve up-to-date information as needed. We provide an HTTP REST API for standard requests, as well as Socket.io for real-time data access. This method is ideal for server-client integrations, personal scripts, and other applications.

Let Our Systems Push Data to Your API​

For a more permanent approach, you can set up a data flow that allows our systems to push real-time traffic directly to your API as soon as it arrives on our servers. This method ensures continuous updates without the need for constant requests, making it an excellent choice for server-to-server integrations.

Our cloud platform supports InterUSS services, enabling the exchange of flight data with distributed UTM systems. If your system already implements the InterUSS protocol, it is likely capable of exchanging data with our platform, ensuring a smooth integration process.

Operating within the same Distributed Situational Awareness (DSS) instance as our system facilitates seamless data exchange between both platforms, enhancing operational coordination.

To learn more, visit the InterUSS Platform Official Website.

Currently Supported Services:

• Remote ID
• Strategic Deconfliction
• Geo-awareness

If you need to integrate our hardware directly without relying on cloud services, there are several options available to achieve this.

On-board Integration with Existing Systems​

Some of our products are specifically designed for integration with existing systems. For detailed instructions, please refer to the user manuals for each product:

• Integration Manual for Dronetag DRI
• Integration Manual for Dronetag BS

Integration via Bluetooth​

All Dronetag devices utilize standard Remote ID data formats that comply with the FAA's Remote Identification of Unmanned Aircraft Systems (UAS) rule and the ASTM F3411-22 standard, ensuring seamless interoperability and regulatory compliance.

If you're interested in receiving Remote ID data directly via Bluetooth, you can create your own Remote ID application to decode the signals transmitted by our devices according to the standard.

Please note that we do not provide an SDK for Remote ID decoding or documentation for our proprietary Bluetooth characteristics. If you have a specific project you’d like to discuss with us, please don’t hesitate to contact us for further assistance.

The REST API is best for retrieving absolute current & historical telemetry data, accessing account data such as assets, devices, aircraft and more. Because you need to request data manually, it's not very suitable for real-time data streaming. For real-time data, we recommend looking at using our Socket.io endpoints.

Obtaining API Credentials​

To access our API, you’ll need to authenticate. There are two ways to do this:

1. Personal Token: Use your personal token to access data on your Dronetag account. This can be created in our app or using API.
2. OpenID Connect: Use OIDC for more advanced authentication methods and allowing your application to access other users' private data.

Consuming the API​

Once you have your credentials, you’re ready to start using the API. We recommend familiarizing yourself with the API documentation, which outlines all available endpoints and the data structures you’ll be working with.

Understanding DUMP data format​

Our API uses a variety of data schemas, each designed for a specific API resource. One of them is used more consistently across our services, and that is the Dronetag Unified Message Protocol (DUMP) format. If you're dealing with Remote ID data, this protocol will be particularly important to understand.

To help you better understand, we've created a detailed guide that breaks down the structure of DUMP messages and explains how to work with them effectively:

Conditions for Telemetry Request Parameters​

Keep in mind that when making telemetry requests to our airspace endpoints (/v2/airspace/*), you must specify both a time range (from and to) and a geographical region (bbox).

There are a few exceptions to this requirement:

• If you provide an operation_id, no other parameters are needed.
• If you specify a uas_id, you can omit the bbox geographical region, but the time range is still required.

Please note that the bbox size is limited and intended for moderately sized regions. It is not possible to use bbox to cover large areas such as entire countries, continents, or the world.

If this condition poses a challenge, we recommend exploring our data push methods.

Additional Guides​

We offer several other guides to help you navigate common use cases with our API. Whether you’re looking to retrieve current airspace information or historical data, these resources will give you the tools you need:

Explore more guides through the left sidebar to enhance your API usage.

The Socket.io API is designed for real-time telemetry data streaming, offering only live telemetry updates (no historical or absolute data). This guide will walk you through setting up a real-time connection between Dronetag and your application using Socket.io.

Connection Parameters​

To establish a connection, use the following configuration parameters in your Socket.io client:

• Host: https://api.dronetag.app
• Path: /v2/airspace/socket.io
• Client Version: v3 or v4

Choosing a Socket.io Client​

Socket.io is supported by many libraries across various programming languages. You can find the full list of supported client implementations here.

Authenticating Your Session​

You can authenticate your Socket.io session using the same access token that you use for REST API requests. Refer to the API credentials guide for details on obtaining your access token.

Native Socket.io Authentication​

For clients that support native Socket.io authentication, you can pass the access token directly in the auth configuration option.

let socket = io("https://api.dronetag.app", {
  path: "/v2/airspace/socket.io",
  auth: "eyJhbGciOiJSUzI1NiIsInR5c...",
});

More information on using Socket.io authentication can be found in the Socket.io documentation.

Using a Bearer Token in the Handshake Request​

If your client does not support the auth option, you can send the access token as an Authorization header in the handshake request:

let socket = io("https://api.dronetag.app", {
  path: "/v2/airspace/socket.io",
  extraHeaders: { Authorization: "Bearer eyJhbGciOiJSUzI1NiIsInR5c..." }
});

This approach is also handy when using tools like Postman for testing, which typically don’t support native authentication. You can simply add the Authorization header in the Headers tab of Postman.

Subscribing to Events​

Once connected, you can listen for several types of telemetry events:

• telemetry_ua – Unmanned Aircraft telemetry
• telemetry_operator – Operator telemetry
• telemetry_system – System telemetry
• operation – Updates on ongoing operations

For the most up-to-date and comprehensive list of available events, refer to our AsyncAPI documentation.

Setting and Updating the Viewport​

Just as with the REST API, you must specify the geographical region your application is interested in. For more details, see the conditions for REST API telemetry requests.

After connecting, your client must send an initial viewport event to define the geographical area it wants to monitor. Additionally, the client must update this area by sending new viewport events whenever the region of interest changes. If you don't set a viewport, your session won't receive any telemetry data.

For example, in Dronetag’s own applications, the map moves dynamically based on user interactions. After establishing a connection, the app sends the initial viewport, and as the user moves the map, the viewport is updated. It's important to debounce these updates to prevent rapid viewport changes, which could lead to the server disconnecting your clients.

Always set your viewport carefully. It is important to cover the whole area of your interest. On the other hand, do not set viewports too large, as it could provide data you do not want and also cause performance issues. It is recommended to add a sufficient margin of a few kilometers (or miles, if you wish) on each side. The maximal supported viewport area is around 6 million square kilometers, but try avoiding such extreme values.

For example, to set the viewport to Prague, you may use something like emit("viewport", "14,49.9,15,50.3").

Example Code Snippets​

Below are some quick examples to help you get started with Socket.io in different programming languages:

const { io } = require('socket.io-client');

const socket = io('https://api.dronetag.app', {
  path: '/v2/airspace/socket.io',
  auth: 'eyJhbGciOiJSUzI1NiIsInR5c...'
});

socket.on('connect', () => {
  socket.emit('viewport', viewportRectangle.getBounds().toBBoxString());
});

socket.on('telemetry_ua', (data) => {
  console.log('UA telemetry received:', data);
});

import socketio

sio = socketio.Client()

@sio.event
def connect():
    sio.emit('viewport', viewportRectangle.get_bounds().to_bbox_string())

@sio.event
def telemetry_ua(data):
    print(f'UA telemetry received: {data}')

sio.connect(
    'https://api.dronetag.app',
    socketio_path='/v2/airspace/socket.io',
    auth='eyJhbGciOiJSUzI1NiIsInR5c...'
)

sio.wait()

Here, you will learn how to authenticate your requests to access resources available on Dronetag accounts.

We offer two authentication methods: Personal Access Tokens (PATs) and OpenID Connect. Each method serves different use cases, so please read on to determine which is best suited for your project.

Using Personal Access Tokens (PATs)​

If you plan to work with personal data from your own Dronetag account, such as post-processing data, creating a personal command-line interface (CLI) tool, or integrating data into other software, Personal Access Tokens (PATs) are available for easy and straightforward access to the API.

These tokens provide a simple to use, although less secure, method for accessing your resources via our API services. For more robust integrations intended for public access, we recommend considering the OpenID Connect method instead.

Creating a new token​

{
    "password": "hunter2",
    "expires_at": "2025-09-09"
}

After you issue a new Personal Access Token, be sure to store this token securely. You won't be able to retrieve this token again.

Using tokens to authorize requests​

You can now use the token in X-Personal-Access-Token HTTP header when making requests.

Example request with PAT​

POST /v2/airspace/telemetry/ua HTTP/1.1
Host: api.dronetag.app
Accept: */*
X-Personal-Access-Token: 4c5250130bbce349.b0dc901facd944e999b32ebf984c5250130bbce349b0dc901facd944e999b32e

Implementing OpenID Connect​

By implementing Sign in with Dronetag, you can allow users to access their data through your application. This method is more reliable and offers a standardized approach to authentication.

Understanding OpenID Connect (OIDC)​

Our implementation is based on OpenID Connect (which should not be confused with OpenID). OIDC allows you to leverage existing libraries and may already be supported by your application. Learn more on the OpenID Foundation website.

To utilize OIDC in your application, you will need your own client ID and secret. If you have not yet received these credentials, please contact us for assistance.

Implement authentication in your application​

curl -X POST "https://auth.dronetag.app/realms/dcp/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=password" \
-d "client_id=<your-client-id>" \
-d "client_secret=<your-client-secret>" \
-d "username=<your-username>" \
-d "password=<your-password>"

{
    "access_token": "eyJhbGc...",
    "expires_in": 1200,
    "refresh_expires_in": 604800,
    "refresh_token": "eyJhbGc...",
    "token_type": "Bearer",
    "not-before-policy": 0,
    "session_state": "35d764ee-c27c-4763-bc05-5ffa2e2b822e",
    "scope": "email"
}

The table above assumes your application has been assigned its "Client ID" and "Client Secret". For testing purposes, you may use a generic Client ID of dronetag-integration-test with no secret needed. For production use, each individual application should be assigned its own unique Client ID. Otherwise, limits on the volume of pulled data may be applied. Contact Dronetag support to get your credentials.

Using Access Tokens​

Both Personal Access Tokens and access tokens retrieved using OIDC can be added as a Bearer token in the Authorization header to authenticate your API requests.

Example Request​

POST /v2/airspace/telemetry/ua HTTP/1.1
Host: api.dronetag.app
Accept: */*
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICItQllNT2...

Refreshing Tokens​

Access tokens issued as JWTs are short-lived and require refreshing upon expiration. We recommend reviewing the following resources for more information on refresh tokens and their secure usage:

• What Are Refresh Tokens and How to Use Them Securely - Auth0
• Understanding Refresh Tokens, Access Tokens, and ID Tokens in OIDC Protocol - Logto
• Refresh Access Tokens and Rotate Refresh Tokens - Okta

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.

How to Access the Integration Portal​

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.

What Can You Configure?​

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:

• Connection Protocol: Choose between HTTP webhooks, MQTT, TCP, or UDP.
• Target Address: Direct the data to your production or staging API endpoint—it’s your call.
• Output Format: Besides our standard JSON format, we support various UTM systems. See Protocols and Formats for recommended combinations.
• Traffic Throttling: To avoid overloading your servers, you can limit the number of requests at the cost of some latency.
• Authentication: Choose from various authentication methods, including HTTP Basic Authentication, custom HTTP headers, OAuth 2.0, and more.
• ... and more

Setting Up Your First Distribution Target​

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.

1. Log in to the Integration Portal with your Dronetag account, or create a new one.
2. On the main page, you’ll see all the distributions you’ve created.
3. Create a new distribution target by clicking the Add New button.
4. Fill out the form to configure your target. The following sections on this page will help guide you through the setup.
5. Save the target and allow a few minutes for the changes to take effect.
6. You can check for communication or configuration errors by viewing the server logs. Find your newly created distribution on the main page and click View & Edit.

Pausing or Stopping the Distribution​

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.

What’s Next?​

• After setting up your integration, check if it's working properly.
• Learn more about our DUMP JSON format.
• If this integration method doesn’t suit your needs, check out our guide for choosing the best integration method.

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​

Compatibility Matrix​

Product Names​

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

Portal Names and Security Options​

The Integration Portal uses these connection labels:

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.

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.

My Account​

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.

Device Group​

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.

Partner Integration​

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:

• Full/display company/app name
• Logo URL (optional) – horizontal logo to improve brand recognition
• Description (optional) – short text describing your company/app/platform
• Website URL - link to your website
• Manager account – Dronetag account that will be allowed to select this partner integration as a data source in the integration portal
• Client ID configuration (optional) - a preference if you wish to require users to enter identification before enabling the integration

All Public Data (Deprecated)​

Previous requirements: None
Data shared: All public data of all Dronetag users (but not private data)

This data source previously allowed all public data available in the Dronetag App to be shared with any third party via the integration portal.

To enhance user experience and privacy, this option has been deprecated and is no longer available.

The most common distribution type uses HTTP protocol to distribute the data.
For each telemetry message, a new HTTP request is created and sent to your service's HTTP server.

Specific configuration​

Currently, only additional HTTP headers can be set using the specific configuration.

Example specific configuration​

Following is an example of configuration JSON where custom headers are used to send a Bearer token with each request.

{
  "target_additional_http_headers": {
    "X-My-Custom-Id": "12345"
  }
}

If your service is equipped with an MQTT Broker Server, you can use the MQTT Client type to connect to your server and publish the data.

Specific configuration​

Example specific configuration​

Following is an example of configuration JSON.

{
  "mqtt_dist_client_id": "dronetag_0001",
  "mqtt_dist_transport": "tcp",
  "mqtt_dist_tls": false,
  "mqtt_dist_json_datastream_topic": "dronetag/telemetry/{msgtype}",
  "mqtt_dist_publish_qos_default": 0
}

Using {msgtype} in topic name​

If you use Dronetag DUMP format and you'd like to send different types of messages to different topics, you can use the {msgtype} placeholder in the topic name. It will be replaced with the actual message type before sending. For example, if the message type is "UA telemetry", the topic dronetag/telemetry/{msgtype} will become dronetag/telemetry/tele-ua.

Available message types are:

• tele-ua - UA telemetry messages
• tele-operator - Operator telemetry messages
• tele-system - System telemetry messages
• operation-update - Operation update messages

Refer to the 'Understanding DUMP' page for more information about the message types.

Configuration recommendations​

• Usually a valid Target Port is required to be set.

This distribution type uses plain TCP or UDP socket to distribute the data.

Specific configuration​

Example specific configuration​

Following is an example of configuration JSON

{
  "embed_metadata": true
}

Configuration recommendations​

• The 'Target port' must be set
• We recommend using the AES cipher authorization type to keep the traffic secure

Data Push uses two separate filters before sending data to your target:

1. The Data Source setting controls which messages are eligible for the distribution target.
2. The Output Format setting controls which eligible message types can be represented and sent.

For example, a target using the My account data source can receive only messages accessible to that account. If the same target uses a partner-specific UAV-position format, only eligible aircraft position messages are sent because that format cannot represent operator position, system telemetry, or operation updates.

Message Types by Output Format​

DUMP JSON and DUMP JSON Typed are the best choices when your target needs the complete Data Push message set.

System telemetry can be disabled for a target with the distribute_system_telemetry connection setting.

After setting up your first distribution, your next step will likely be monitoring to ensure it's working correctly. You can do this in several ways.

Check the Status in the Integration Portal​

To view the current status of your distribution, visit the Integration Portal and confirm that your distribution is enabled and configured correctly.

Click on the View & Edit link to see details such as uptime and statistics for the last 24 hours. You'll also see a small chart that provides a quick overview of how many messages were sent through this distribution during that period.

Monitor the Status with Prometheus / OpenTelemetry​

If you want more advanced monitoring, including historical data and alerts, you can integrate Prometheus to scrape metrics from our system. This feature is available for all integration portal users and provides detailed data for each running integration.

To visualize the data, we recommend using Grafana.

Getting the Metrics URL​

1. Log in to the Integration Portal with your Dronetag account, or create a new one.
2. Find the distribution target you're interested in and click View & Edit.
3. Click the Get Prometheus Metrics button.
4. You’ll see the metrics in Prometheus/OpenMetrics format.
5. Use your preferred tool to scrape this URL periodically (see the next section for more details).

The URL format will look like this:

https://relay.dronetag.app/metrics/[[your_distribution_id]]

Make sure to note your distribution ID.

Scraping Metrics with Prometheus​

Prometheus is an open-source monitoring system that can scrape our metrics export. To learn more and find installation instructions, refer to the official Prometheus documentation.

Here’s a recommended configuration to start scraping our metrics:

global:
  scrape_interval: 10s
scrape_configs:
  - job_name: 'dronetag_distribution_metrics'
    scrape_interval: 10s
    metrics_path: '/metrics/[[your_distribution_id]]'
    static_configs:
      - targets: ['relay.dronetag.app']

This configuration will scrape metrics every 10 seconds from the URL: https://relay.dronetag.app/metrics/[[your_distribution_id]].

Available Metrics​

Visualizing Data with Grafana​

Grafana is an open-source monitoring and analytics tool that works with Prometheus as a data source.

Check out the guide 'Get started with Grafana and Prometheus' to learn how to install Grafana and set up Prometheus as a data source.

Example Grafana Dashboard​

We provide a basic Grafana dashboard example. You can import the JSON file into your Grafana instance and modify it to suit your needs.

{ "annotations": { "list": [ { "builtIn": 1, "datasource": { "type": "grafana", "uid": "-- Grafana --" }, "enable": true, "hide": true, "iconColor": "rgba(0, 211, 255, 1)", "name": "Annotations & Alerts", "target": { "limit": 100, "matchAny": false, "tags": [], "type": "dashboard" }, "type": "dashboard" } ] }, "editable": true, "fiscalYearStartMonth": 0, "graphTooltip": 0, "id": 47, "links": [ { "asDropdown": false, "icon": "cloud", "includeVars": false, "keepTime": false, "tags": [], "targetBlank": false, "title": "Dronetag Integration Portal", "tooltip": "", "type": "link", "url": "https://integrations.dronetag.app" } ], "liveNow": false, "panels": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "fieldConfig": { "defaults": { "color": { "mode": "thresholds" }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "dark-purple", "value": null } ] }, "unit": "string" }, "overrides": [] }, "gridPos": { "h": 3, "w": 16, "x": 0, "y": 0 }, "id": 3, "options": { "colorMode": "value", "graphMode": "none", "justifyMode": "auto", "orientation": "horizontal", "reduceOptions": { "calcs": [ "lastNotNull" ], "fields": "/^relay_distribution_name$/", "values": false }, "text": { "valueSize": 40 }, "textMode": "value" }, "pluginVersion": "10.1.1", "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "relay_messages_read_created{distribution_id=\"$distribution_id\"}", "format": "table", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "transformations": [], "type": "stat" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "fieldConfig": { "defaults": { "color": { "mode": "thresholds" }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "green", "value": null }, { "color": "dark-blue", "value": 80 } ] }, "unit": "dateTimeFromNow" }, "overrides": [] }, "gridPos": { "h": 3, "w": 8, "x": 16, "y": 0 }, "id": 2, "options": { "colorMode": "value", "graphMode": "none", "justifyMode": "center", "orientation": "horizontal", "reduceOptions": { "calcs": [ "lastNotNull" ], "fields": "/^Created$/", "values": false }, "textMode": "value_and_name" }, "pluginVersion": "10.1.1", "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "relay_messages_read_created{distribution_id=\"$distribution_id\"}", "format": "time_series", "instant": false, "legendFormat": "Created at", "range": true, "refId": "A" } ], "transformations": [ { "id": "calculateField", "options": { "alias": "Created", "binary": { "left": "Created at", "operator": "*", "reducer": "sum", "right": "1000" }, "mode": "binary", "reduce": { "reducer": "sum" }, "replaceFields": true } } ], "type": "stat" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "Average rates of sent (distributed) messages. Dotted line shows source input rate, which can be higher if there are filters applied (such as filter to specific device group).", "fieldConfig": { "defaults": { "color": { "mode": "palette-classic" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "bars", "fillOpacity": 100, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 0, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "never", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "off" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "green", "value": null }, { "color": "red", "value": 80 } ] }, "unit": "mps" }, "overrides": [ { "matcher": { "id": "byName", "options": "Input rate" }, "properties": [ { "id": "custom.lineWidth", "value": 1 }, { "id": "custom.lineStyle", "value": { "dash": [ 2, 6 ], "fill": "dot" } }, { "id": "color", "value": { "mode": "fixed" } }, { "id": "custom.drawStyle", "value": "line" }, { "id": "custom.fillOpacity", "value": 0 } ] } ] }, "gridPos": { "h": 8, "w": 24, "x": 0, "y": 3 }, "id": 1, "interval": "15s", "maxDataPoints": 128, "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_messages_distributed_total{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "Distributed rate", "range": true, "refId": "A" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_messages_read_total{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "hide": false, "instant": false, "legendFormat": "Input rate", "range": true, "refId": "B" } ], "title": "Average distribution rate", "type": "timeseries" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "The duration of how long it takes to convert the source input data to the output format. Includes filtering or other data pre-processing.", "fieldConfig": { "defaults": { "color": { "mode": "fixed", "seriesBy": "last" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "line", "fillOpacity": 0, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 1, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "auto", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "line" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "blue", "value": null } ] }, "unit": "s" }, "overrides": [] }, "gridPos": { "h": 8, "w": 12, "x": 0, "y": 11 }, "id": 4, "interval": "15s", "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_message_conversion_seconds_sum{distribution_id=\"$distribution_id\"}[$__rate_interval]) / rate(relay_message_conversion_seconds_count{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "title": "Average conversion duration", "type": "timeseries" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "The duration of how long it takes to distribute the data. The largest part is usually the server latency. Some distribution types can be missing a support for this metric.", "fieldConfig": { "defaults": { "color": { "mode": "thresholds", "seriesBy": "max" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "line", "fillOpacity": 0, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 1, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "auto", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "dashed" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "blue", "value": null }, { "color": "dark-orange", "value": 0.7 }, { "color": "semi-dark-red", "value": 1 } ] }, "unit": "s" }, "overrides": [] }, "gridPos": { "h": 8, "w": 12, "x": 12, "y": 11 }, "id": 5, "interval": "15s", "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_message_distribution_seconds_sum{distribution_id=\"$distribution_id\"}[$__rate_interval]) / rate(relay_message_distribution_seconds_count{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "title": "Average distribute duration", "type": "timeseries" } ], "refresh": "", "schemaVersion": 38, "style": "dark", "tags": [ "dronetag" ], "templating": { "list": [ { "current": { "selected": false, "text": "cc2129b7-30e4-469e-8b13-92e7e097d528", "value": "cc2129b7-30e4-469e-8b13-92e7e097d528" }, "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "definition": "label_values(relay_messages_read_total,distribution_id)", "hide": 0, "includeAll": false, "label": "Distribution ID", "multi": false, "name": "distribution_id", "options": [], "query": { "query": "label_values(relay_messages_read_total,distribution_id)", "refId": "PrometheusVariableQueryEditor-VariableQuery" }, "refresh": 1, "regex": "", "skipUrlSync": false, "sort": 0, "type": "query" } ] }, "time": { "from": "now-1h", "to": "now" }, "timepicker": { "nowDelay": "", "refresh_intervals": [ "5s", "10s", "30s", "1m", "5m" ] }, "timezone": "", "title": "Dronetag Single Distribution Monitoring", "uid": "f2370455-bdac-4098-baf5-ea8857bc199d", "version": 5, "weekStart": "" }

If you're encountering issues with your Data Push integration or distribution setup, this guide will help you identify and resolve common problems.

Common Issues and Solutions​

1. Distribution Not Sending Data​

If your distribution has been set up but no data is being sent, try the following steps:

• Check Distribution Status: Log in to the Integration Portal and make sure your distribution is active and properly configured. Look for errors or warnings in the logs.
• Verify Target Address: Ensure that the target address (API endpoint, MQTT broker, etc.) is correct. Test the connection to make sure your service is reachable.
• Firewall or Network Restrictions: Confirm that no firewall or network rules are blocking incoming data from our servers. Make sure the necessary ports are open (especially when using custom ports for TCP/UDP).

2. Data Delays or High Latency​

If data is delayed or experiencing high latency, the issue might be related to:

• Traffic Throttling: Check if you've configured traffic throttling in the Integration Portal. Highly throttled set-ups can increase latency.
• Network Performance: Analyze your server's network performance and response times. High latency can sometimes be due to slow processing on your server. You can use our Prometheus metrics monitoring to check the request latency against your servers.

3. Authentication Failures​

If your distribution is failing due to authentication errors:

• Check Authentication Method: Verify that the correct authentication method (HTTP Basic Authentication, OAuth 2.0, custom headers, etc.) is configured in the Integration Portal.
• Credentials: Ensure your API credentials or tokens are up-to-date and correctly set in your target service.

4. Failed Message Delivery​

If the system is failing to deliver messages, or if you notice a lower count of distributed messages compared to input messages:

• Check Filters: The system may be filtering out certain messages based on your configuration. Review the Data Source configuration item.
• Review Server Logs: Look at the distribution server logs for any error messages or warnings. You can access these through the Integration Portal by clicking View & Edit on the distribution.
• Connection Issues: If the target service is down or unreachable, the system will not be able to deliver messages. Make sure your service is online and available.

5. Prometheus Metrics Not Showing Up​

If you're using Prometheus to scrape metrics but aren't seeing any data:

• Metrics URL: Double-check the metrics URL in the Prometheus configuration. Ensure it's in the correct format: https://relay.dronetag.app/metrics/[[your_distribution_id]].
• Prometheus Configuration: Review your prometheus.yml configuration file to confirm that the metrics path is correct and that Prometheus is scraping at the correct interval.
• Distribution Errors: If distribution cannot start properly or is failing, the metrics endpoint can usually be empty. Check the distribution server logs if it's running properly.

Need More Help?​

If these steps don’t resolve your issue, feel free to contact our support team for assistance. Make sure to include any relevant details, such as error logs or screenshots, to help us quickly diagnose the problem.

This guide is for our customers and partners looking to integrate Dronetag solutions into their systems. Below, you’ll find helpful resources and links tailored to your specific integration needs.

Before proceeding, it's important to clarify your integration requirements:

• What type of data do you need, and in what formats? What protocols does your system prefer?
• What environment will the integration operate in—client-side, server-side, or both?
• Do you prefer to initiate the data exchange from your system, or would you rather have Dronetag stream data directly to you?

One-Time Data Import into Another Application​

“I want to just import my flight data to another application.”

If real-time access and continuous data collection aren’t required, you can export data from our apps in open formats such as CSV, KML, or GPX.

Learn more about the Dronetag app here.

Scripting to Collect Historical Flight Data​

“I want to write a script to collect all my flight data from last week in KML format.”

For automated collection of historical data, our REST API allows exporting in multiple formats. By default, we use our JSON format, but you can also request CSV, KML, GPX, or GeoJSON by specifying the desired MIME type in your Accept header.

Since you'll be accessing your own devices under your account, Personal Access Tokens are the most straightforward authentication method for you.

Refer to our guide on obtaining telemetry data or explore our API documentation for more details.

Accessing Real-Time Data for All Your Devices​

“I want to display my Dronetag devices in real-time in different software.”

If real-time data is your priority, we recommend using either an existing integration, or a combination of our REST API and Socket.io real-time API.

Check our getting started page, which lists the currently available existing integrations with our partners and third-party software.

If such integration is not available, you're given an option to integrate with our REST API and Socket.io API. Since you'll be accessing your own devices under your account, Personal Access Tokens are the most straightforward authentication method for you.

See our guide on retrieving real-time data or check out the API documentation.

Displaying User Data in a Client-Side Application​

“I have a web application and I want to allow Dronetag users to display their data in my application and manage their Dronetag assets.”

To allow your users to view their Dronetag data within your client-side application, we recommend integrating OpenID Connect. This enables seamless login using Dronetag accounts directly from your application.

Learn more about API authentication.

Sharing User Telemetry to a Server-Side Solution​

“I have a cloud solution and I would like to collect data from Dronetag devices from other users.”

If you have a server-side application and want to give your users access to their telemetry data in it, we suggest using our integration portal. You can establish a persistent connection between the Dronetag Cloud Platform and your server. Users will then be able to authorize your integration through the Dronetag App, allowing telemetry data from their devices to be sent to your servers.

Start with the Data Push Getting Started guide.

Integrating U-Space Data​

If you need to integrate with U-Space services, we also support U-Space reporting via InterUSS. We can send data to several DSS (Discovery and Synchronization Service) instances. If your system already implements the InterUSS protocol, we may be able to work with your existing DSS or include your DSS instance.

For more details on U-Space integration, refer to our InterUSS section.

Can’t Find What You Need?​

We provide a robust real-time API available for general use. However, if your integration requirements are more complex, we offer dedicated support as part of our Enterprise subscription plan. Contact us to discuss your needs further.

This detailed guide will show you how to retrieve flight data from our API after completing flights with your Dronetag devices.

There are two main approaches depending on what flight details you have. You can either retrieve a list of past flights, select one, and gather all available data for that specific flight, or if you only know the general time frame and location, you can pull a segment of the airspace history. Both options are supported via our REST API.

Retrieving Telemetry for a Single Flight​

This method allows you to retrieve the full telemetry history for one specific flight from a single device. The API response will provide data collected by that device.

1. Authenticate Your API Requests​

   Before proceeding, ensure you have access to the necessary resources. Visit the authentication guide for instructions on how to authenticate your API requests.

2. List Available Flights​

   get/v1/flights/ see API docs »

   Retrieve a list of available flights associated with your authenticated Dronetag account. Take note of the id of the flight you’re interested in.

3. Request the Flight's Telemetry Data​

   get/v2/airspace/telemetry/ua see API docs »

   Use the flight’s id as the operation_id query parameter. This will give you the telemetry data for the selected flight without needing to specify time ranges or geographical areas.

   Our telemetry endpoints support multiple output formats. Choose your preferred format and set it in the Accept header of your request.

   You can also access additional telemetry streams for tracking the UA operator or the RID system.
   For more details, check out the DUMP guide.

   Note

   You may notice a /v1/flights/{id}/telemetry endpoint. However, we recommend using the v2 endpoint, as v1 is planned for deprecation.

Retrieving Airspace History​

This method allows you to pull historical airspace data for a defined location and time period.

1. Authenticate Your API Requests​

   Ensure you have access to the necessary resources. Visit the authentication guide for instructions on how to authenticate your API requests.

2. Choose Your Parameters​

   Based on the information you have, you can retrieve airspace history by either:

   • Specifying a time range (from, to) and geographical region (bbox), or
   • Specifying a time range (from, to) and UAS ID (device serial number, uas_id).

3. Request the Airspace Telemetry Data​

   get/v2/airspace/telemetry/ua see API docs »

   Select your preferred output format and set it in the Accept header of your request.

   You can also access additional telemetry streams for tracking the UA operator or the RID system.
   Learn more about these telemetry types in the DUMP guide.

4. Request Operation Details​

   get/v2/airspace/operation/{operation_id} see API docs »

   While the previous request provides telemetry data, it does not include all the information about the flight, such as the UA's identification and type. To gather additional details, use the Operation API endpoint to retrieve more comprehensive operation information.

This guide explains how to access and visualize real-time telemetry, typically by using a combination of the REST API and real-time Socket.io to monitor airspace activity in real-time.

1. Authenticate Your API Requests​

   Make sure you have the required access to the necessary resources. For detailed instructions, refer to the authentication guide.

2. Set Your Observation Parameters​

   Decide whether you want to monitor a specific geographical area (bbox) or a particular device (uas_id).

   Note: The geographical region has limitations. Large areas such as continents or countries cannot be observed. For details, see the REST API guide.

3. (Optional) Make an Initial Request to Get the Airspace State​

   get/v2/airspace/telemetry/ua?from=-00:05:00&bbox=... see API docs »

   Before starting real-time updates, we recommend fetching the initial airspace state. This helps initialize your application’s state. For example, retrieve the last 5 minutes of airspace data to create a starting point for real-time monitoring.

4. Receive Real-Time Telemetry Updates​

   Option 1: Connect to Socket.io for Real-Time Updates​

   wswss://api.dronetag.app/v2/airspace/socket.io telemetry_ua see API docs »

   Using Socket.io allows you to receive real-time updates with low latency, without needing to worry about time range query parameters. This is the preferred option for responsive applications.

   Option 2: Poll the REST API for Updates​

   get/v2/airspace/telemetry/ua?from=$last_date&bbox=... see API docs »

   Alternatively, you can periodically poll the API for updates. However, this approach is less efficient for applications that need frequent updates.

   If you choose this option, ensure you use the Date header (needs to be converted to ISO 8601) from the last response for the from parameter in subsequent calls, to avoid receiving duplicate data.

   Not Recommended

   Polling is generally not suitable for high-frequency updates. Polling this endpoint with high frequency (> 1 per second) can result in rate limiting errors.

5. Retrieve Operation Details​

   While telemetry data provides real-time flight information, it may not include essential details such as UA identification and type. You can retrieve additional information about the operation itself.

   Option 1: Listen for Operation Updates via Socket.io​

   wswss://api.dronetag.app/v2/airspace/socket.io operation see API docs »

   With Socket.io, you can listen to the operation channel for updates when a new operation is created or existing operations are modified. However, network interruptions can cause data loss, so it's best to combine this with occasional HTTP requests to ensure your application remains in sync.

   Option 2: Use HTTP Requests as Needed​

   get/v2/airspace/operation/{operation_id} see API docs »

   When necessary, you can request the operation details via the Operation API using the operation_id. This will give you the stored information about the airspace operation.

6. Keep Your Viewport Up-to-Date​

   If your application displays a dynamic map or the area of interest changes over time, ensure you update the bbox query parameter in your API requests or send viewport events when using Socket.io.

   For more information, refer to the API documentation and the Socket.io guide.

You can also access additional telemetry streams for tracking the UA operator or the RID system in real time. For more details, see the DUMP guide.

This guide explains how you can monitor the real-time status of your Dronetag device, such as battery charge, LTE, and GNSS signal strengths, and other key metrics. You can retrieve this data using either the REST API or the real-time Socket.io API.

Key Differences from Other Telemetry Types​

Unlike other telemetry data such as Telemetry-UA or Telemetry-Operator, which are sent frequently, telemetry related to the device’s system status (Telemetry-System) is generally sent at lower intervals—typically every 10 to 15 seconds or more.

Learn more about all telemetry types in the DUMP guide.

Monitoring a Specific Device Using UAS ID​

To retrieve the status of your Dronetag device in real-time, you must use the device’s UAS ID, which is equivalent to the serial number of the Dronetag device. Unlike other telemetry types that allow observation based on a geographical region (via bbox), this endpoint does not support monitoring by geographical region. Instead, you’ll need to specify the UAS ID to access data for a particular device.

1. Authenticate Your API Requests​

   Ensure you have access to the necessary resources by authenticating your API requests. You can find more details on the authentication process in the authentication guide.

2. Identify the Device by UAS ID​

   Before making any requests, confirm the UAS ID (serial number) of the device you wish to observe. You can find the UAS ID on the physical Dronetag device, within your account settings in the Dronetag App, or in other API responses.

3. Request Real-Time System Status Data​

   Option 1: Retrieve Data via REST API​

   To access the device's real-time status data through the REST API, use the following endpoint:

   get/v2/airspace/telemetry/system see API docs »

   Set the uas_id query parameter to the serial number of the Dronetag device, and define a time range using the from parameter, or both from and to.

   Option 2: Real-Time Updates via Socket.io API​

   Not available yet

   This option is not yet available

   wswss://api.dronetag.app/v2/airspace/socket.io telemetry_system see API docs »

   For real-time updates, connect to the telemetry_system channel via Socket.io. This method delivers lower-latency updates compared to REST polling.

All of our cloud-connected Dronetag products can be integrated with TAK Server by using our integration portal and can stream their Drone Remote ID data in the Cursor on Target (CoT) format directly to your TAK server in real-time.

Network Remote ID (NRI) devices (such as Dronetag Mini) can stream their UA positions. Direct Remote ID (DRI) receivers (such as Dronetag RIDER or Dronetag Scout) can additionally stream the operator location, and the location of the receiver itself.

Prerequisites​

Before you begin, ensure you have:

• Dronetag account (create at https://dronetag.app/signup)
• Supported Dronetag product(s) registered on your account
  • Supported are Dronetag Mini, Dronetag Mini 4G, Dronetag RIDER, or Dronetag Scout
• Active Pro or Enterprise subscription plan (required for integration portal access)
• TAK Server instance
  • With publicly accessible TAK Server endpoint (IP address or domain name)

How to Set-up​

1. Configure your TAK Server​

   Before setting up the integration, ensure your TAK Server is ready:

   1. Open the required port on your firewall
   2. Configure TAK Server to accept data feeds on this port
   3. Note your connection details:
      • Server IP or domain (e.g., tak.yourcompany.com or 203.0.100.200)
      • Port number (e.g., 8087)

   If unfamiliar with TAK Server configuration, refer to the official TAK Server documentation.

2. Access the Integration Portal​

   Visit https://integrations.dronetag.app and sign in using your account credentials

3. Create New Distribution​

   Create a new distribution using the following configuration:

   Required Settings​

   • Connection type — TCP or UDP Socket
   • Target URI — Your TAK Server address (e.g., tak.yourcompany.com or 203.0.100.200)
   • Target port — Your TAK Server port (e.g., 8087)
   • Output format — Cursor on Target XML

   Leave the other options to default values, or customize to your preferences. Please note that not all options are relevant to TCP+XML integration.

   Data Source Selection​

   Take note of the selected data source. The default, "My account", streams data from all devices registered to your account. Other options include "Device Groups" (a static list of devices) and "Partnered Integration" (allows any Dronetag user to share data to your TAK server). Contact us for details.

   Optional mTLS Authentication​

   If your TAK Server requires mutual TLS authentication, enable the mTLS option and upload the necessary client certificate and private key files in PEM format. This option is available only for TCP connections.

4. Verify the Connection​

   • Allow 2-3 minutes for the integration to initialize and establish connection
   • Turn on your Dronetag device and ensure it's actively transmitting
   • Open your TAK client (ATAK, WinTAK, or iTAK), look for the drone icon appearing on your map at the device's location
   • Verify position updates are occurring in real-time

Troubleshooting​

If you're experiencing issues, try these steps in order:

1. Verify TAK Server connectivity — Ensure your TAK Server IP/domain is correct and publicly accessible. Check that firewall rules allow incoming connections on the specified port.

2. Check device status — Confirm your Dronetag device is powered on, has GNSS lock, shows as "Online" and is visible on the map in your account at https://dronetag.app.

3. Review integration portal logs — Check the "Server logs" section in the integration portal and refresh the view several times (logs are not real-time). Look for connection errors or status messages.

4. Allow time for initialization — The integration needs 2-3 minutes to establish connection. If issues persist beyond this, restart the distribution in the integration portal by disabling and re-enabling the distribution.

If problems persist, contact support with your server logs and configuration details.

Relevant Resources​

• Getting started with Data Push integrations
• TAK Server Official Documentation Resources
• Contact Dronetag Support

When using our API, you will encounter three distinct altitude values related to flight telemetry data points. This section provides an overview of what these values represent, how they are obtained, and how you can utilize them in your applications.

Altitude Values​

• WGS84 HAE (Height Above Ellipsoid) — Altitude above the WGS84 ellipsoid, in meters

  • This is the raw altitude reported directly by the internal GNSS sensor onboard Dronetag devices.
  • It represents the height above the ellipsoid (not the geoid or Mean Sea Level). This is sometimes mistakenly interpreted as MSL, but it’s important to note that WGS84-HAE refers to the ellipsoid height, not sea level.
  • This altitude can have variable accuracy depending on GNSS signal conditions and the limitations of the earth model stored in GNSS receivers.
  • In APIs available as HAE-WGS84

• QNE (Pressure Altitude) — Altitude calculated from barometric pressure, in meters

  • This value is derived from the onboard barometer using a standard sea-level pressure of 1013.25 hPa (QNE).
  • It is highly accurate for relative measurements, such as comparing altitudes of nearby drones, but it may not represent an accurate absolute altitude compared to the ground.
  • Often used in aviation for standard altitude readings, especially when flying at higher altitudes where atmospheric pressure decreases predictably.
  • In APIs available as PA-QNE

• ATO (Above Takeoff Level) — Altitude above takeoff point, in meters

  • This value is calculated as the difference between the current QNE (pressure altitude) and the pressure altitude at the moment of takeoff.
  • It provides a relative height above the initial takeoff point, which can be useful for determining altitude changes during a flight.
  • ATO values are sensitive to atmospheric pressure changes over time, meaning accuracy may degrade during longer flights or significant weather changes.
  • This altitude can sometimes be perceived as AGL (Above Ground Level) when the environment remains consistent and flight has taken off at ground.
  • In APIs available as ATO

Frequently Asked Questions​

Why isn’t there a reliable AGL (Above Ground Level) altitude?​

We do not offer AGL altitude because our devices do not have sensors capable of directly measuring the distance to the ground or terrain at all locations globally. Without consistent and accurate ground-level pressure or elevation data, calculating true AGL altitude is unreliable.

However, users can calculate their own AGL estimates if they have access to reliable ground-level pressure data from their region. Using the raw pressure values reported by the device, you could compare them to known ground-level pressure to estimate the altitude.

Why does my ATO altitude sometimes show negative values?​

The ATO field is calculated relative to the recorded pressure altitude at takeoff. There are two key factors that can cause negative values:

1. Takeoff Pressure: If you start tracking your flight when the drone is already airborne (e.g., 10m above the ground), the takeoff pressure will reflect that height. When the drone lands, the height will then show a negative value (e.g., -10m) because it's now below the original takeoff point.

2. Pressure Changes Over Time: Atmospheric pressure changes throughout the day due to weather conditions. If you're tracking a long flight that spans hours, the height might gradually drift because the reference pressure from takeoff no longer matches the current ground pressure. This can lead to incorrect readings, especially for long-duration flights.

Why does my commercial drone show AGL altitudes, but Dronetag does not?​

Most commercial drones do not actually show AGL altitude; instead, they use a method similar to our ATO (height above takeoff). The drone's controller records the takeoff pressure and subsequently displays the difference between the takeoff altitude and the current altitude. This is presented as the drone's height above ground, even though it's technically just height relative to the takeoff point, not true AGL.

The DUMP (Dronetag Unified Message Protocol) is Dronetag's internal messaging format, used consistently across all our services. Whether you are interacting with our REST API, Socket.io, or integrating through our portal, you can rely on DUMP to be the standard data exchange format.

The current version is DUMP v1.

DUMP supports the following message types:​

• Operation ⏺︎
• OperationUpdate ⏺︎
• Telemetry-UA ⏺︎ (often shortened as TELE-UA)
• Telemetry-Operator ⏺︎ (TELE-Operator)
• Telemetry-System ⏺︎ (TELE-System)

The details of these message types, including when and how they are used, are explained further below.

DUMP Message Types​

Operation (or OperationUpdate)​

📋 See the full JSON schema in our API documentation

An Operation message contains static information about a specific flight. The purpose of separating this data into an operation object is to avoid repeating unchanged information, such as the drone’s serial number or the Remote ID (RID) module’s ID, in every telemetry message.

It’s important to understand that a single operation may not always correspond directly to a single flight. In cases where a flight is recorded using multiple systems—like a combination of Network Remote ID and ground-based Direct Remote ID receivers—the flight might be divided into multiple operations.

The difference between Operation and OperationUpdate is significant. The Operation message represents the full state of the flight at the time of the request and is returned when you query through the REST API. On the other hand, OperationUpdate messages represent partial updates, sent primarily in real-time scenarios (e.g., via Socket.io or our integration portal). OperationUpdate only includes recent changes, not the entire state.

Example​

{
  "id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "status": "current",
  "uas_operator_id": "FIN87astrdge12k8",
  "ua_classification": "class1",
  "ua_classification_type": "open",
  "ua_identifiers": [
    {
      "type": "serial_number",
      "value": "15968AB92D361"
    },
    {
      "type": "caa_assigned",
      "value": "JA.JU12345ABCDE"
    }
  ],
  "authentication": [],
  "descriptions": []
}

Telemetry-UA​

📋 See the full JSON schema in our API documentation

The Telemetry-UA message is the primary data object for Remote ID. It provides a snapshot of the unmanned aircraft’s (UA) geographical position, status, and other relevant information required by Remote ID regulations.

Each Telemetry-UA message is associated with an Operation through the operation_id field. Every Remote ID-enabled device generates Telemetry-UA messages during operation.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "operational_state": "airborne",
  "location": {
    "latitude": 50.073873, "longitude": 14.466586, "accuracy": 50
  },
  "altitudes": [
    { "type": "WGS84", "value": 192.5, "accuracy": 10 },
    { "type": "QNE", "value": 323.1, "accuracy": 0.5 },
    { "type": "AGL", "value": -10.0, "accuracy": 0.5 }
  ],
  "velocity": {
    "heading": 92, "horizontal_speed": 9.72, "vertical_speed": 1.22, "speed_accuracy": 0.5
  },
  "air_pressure": 1017.712
}

Telemetry-Operator​

📋 See the full JSON schema in our API documentation

The Telemetry-Operator message tracks the operator’s location. Some UAV systems report the pilot’s real-time position through their control equipment. Standard Remote ID drones can provide operator tracking, while Remote ID modules typically only supply the takeoff location.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "location": {
    "latitude": 50.073873, "longitude": 14.466586, "accuracy": 50
  },
  "altitude": { 
    "type": "WGS84", "value": 202.5, "accuracy": 10
  },
  "source_type": "take_off"
}

Telemetry-System​

📋 See the full JSON schema in our API documentation

The Telemetry-System message provides information about the status of the Remote ID module itself, rather than the aircraft. It includes details on battery charge, GNSS connectivity, LTE signal, and other system parameters. Currently, only Dronetag devices generate Telemetry-System messages.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "system_type": "rid_module",
  "system_status": "operational",
  "power_source": {
    "type": "battery",
    "input_voltage": 4.11,
    "charge_percentage": 90,
    "is_being_charged": false
  },
  "lte_connectivity": {
    "status": "connected",
    "rsrq": -10,
    "rsrp": -97,
    "snr": 9,
    "tac": "291E",
    "cell_id": "555CA02"
  },
  "gnss_connectivity": {
    "status": "connected",
    "satellites": 12
  }
}

Dronetag provides a simulation tool called Mocker that lets you test your integration during development without a physical device. With Mocker, you can create virtual flights and verify that your system correctly receives and processes Dronetag data.

👉 https://mocker.dronetag.app

Prerequisites​

• Dronetag account — create one for free if you don't have one
• Virtual Mocker device registered to your account (see below)
• Access to the Mocker application — typically granted along with your first virtual device

Obtaining virtual devices​

To get a virtual device, contact us with your Dronetag account details. We are generally happy to provide virtual devices for testing and development purposes. Once a virtual device is registered to your account, you can use it to simulate flights and test your integration.

Creating a simulation​

Mocker supports two simulation engines depending on the type of device you want to simulate:

NRI device simulation (nri_via_live)​

An NRI simulation mimics a device that reports its own position to the network. Only one identifier is needed because the simulated device reports itself.

1. Open the Mocker application and sign in
2. Tap anywhere on the map to place a new simulation
3. Select the nri_via_live engine
4. Choose a flight scenario
5. Under UAS Identifier, select one of your Mocker devices — it will act as the NRI device
6. Configure any remaining parameters for your chosen scenario and click Create

DRI receiver device simulation (dri_via_funnel)​

A DRI receiver simulation mimics a device that detects and reports nearby Remote ID aircraft. This requires two identifiers: one for the receiver and one for the detected aircraft.

1. Open the Mocker application and sign in
2. Tap anywhere on the map to place a new simulation
3. Select the dri_via_funnel engine
4. Choose a flight scenario
5. Under UAS Identifier, enter any valid Remote ID ANSI serial number — this represents the aircraft that your receiver detects
6. Under Sensor ID, select one of your Mocker devices — it will act as the DRI receiver
7. Configure any remaining parameters for your chosen scenario and click Create

Controlling simulations​

Once created, the simulated device appears on the map and in the left sidebar. From the sidebar you can:

• Pause the simulation
• End the simulation gracefully
• Force kill the simulation — use this only to test a lost-connection scenario

As part of our improvements, Dronetag is transitioning to region-based and timeline-based telemetry retrieval. This change requires you to update how you query telemetry and real-time data by specifying a geographical region or time range for telemetry retrieval. Follow this guide to ensure a smooth transition to the new system.

Affected Areas​

• All HTTP requests querying post-flight telemetry from api.dronetag.app
  • Endpoints:
    • https://api.dronetag.app/v1/flights/*/telemetry*
    • https://api.dronetag.app/v1/devices/*/status-history
• All HTTP requests querying live telemetry from live.dronetag.app
  • Endpoints:
    • https://live.dronetag.app/api/v2/airspace/overview
    • https://live.dronetag.app/api/v2/devices/*/telemetry
    • https://live.dronetag.app/api/v2/devices/*/status_history
    • https://live.dronetag.app/api/v2/flights/*/telemetry
• All Socket.IO connections for real-time flight telemetry from live.dronetag.app

Key Changes​

• Geographical bounds or UAS ID (device serial number) are now required for all telemetry retrievals.
• The service has switched from UAS ID to Operation ID for identifying flying objects.
• Our telemetry endpoints now use a new data format called DUMP, which will be consistently used across our services.
• Several endpoints, including https://live.dronetag.app/api/v2/airspace/overview, will be deprecated by February 2025.

Migration Timeline​

• February 2025: All deprecated API and Socket.IO endpoints on live.dronetag.app will be removed. Complete your migration by this date.

Step-by-Step Migration​

1. Migrate to api.dronetag.app/v2/airspace for Telemetry Retrieval​

To retrieve telemetry, replace live.dronetag.app queries with api.dronetag.app/v2/airspace.

Replace GET https://live.dronetag.app/api/v2/airspace/overview​

• Use GET https://api.dronetag.app/v2/airspace/telemetry/ua.
• Specify a time range, geographical bounds, or UAS ID.
• Note: Flying objects are now identified by Operation ID. Retrieve the UAS ID using /operations/{operation_id}.

Replace GET https://live.dronetag.app/api/v2/devices/*/telemetry​

• Use GET https://api.dronetag.app/v2/airspace/telemetry/ua?uas_id=xxx with a UAS ID filter.
• You may need /operations/{operation_id} to retrieve the UAS ID.

Replace GET https://live.dronetag.app/api/v2/devices/*/status_history​

• Device status history is now part of system telemetry.
• Use GET https://api.dronetag.app/v2/airspace/telemetry/system?uas_id=xxx with a UAS ID filter.

Replace GET https://live.dronetag.app/api/v2/flights/*/telemetry​

• Flight telemetry is now linked to Operation ID.
• Use GET https://api.dronetag.app/v2/airspace/telemetry/ua?operation_id=xxx.

2. Migrate to api.dronetag.app/v2/airspace for Socket.IO Connections​

• Socket.IO services on live.dronetag.app will be deprecated. Use api.dronetag.app/v2/airspace for real-time telemetry.
• After connecting, send a viewport message to define the geographical region you are monitoring. Regular updates are required during the session.
• Refer to the Getting Started with Socket.io page for details.

3. Migrate to api.dronetag.app/v2/airspace for Post-Flight Data​

Post-flight telemetry is now retrieved through the same API as real-time data. Use your flight_id as operation_id in new requests.

Replace GET https://api.dronetag.app/v1/flights/*/telemetry*​

• Use GET https://api.dronetag.app/v2/airspace/telemetry/ua?operation_id=xxx with Operation ID and flight start/end times.

Replace GET https://api.dronetag.app/v1/flights/*/status-history*​

• Use GET https://api.dronetag.app/v2/airspace/telemetry/system?operation_id=xxx with Operation ID and flight start/end times.

As we roll out updates to improve our cloud platform, it's essential to migrate your authentication method to our new system. This guide will help you update to the reworked authentication layer, which includes enhanced security, better compatibility, and the introduction of OpenID Connect (OIDC) support. Please follow the steps below to ensure a smooth transition.

Affected Areas​

• All API requests – both authorized and non-authorized.
• All authentication requests – we have changed the service responsible for issuing access tokens.

Key Changes​

• Deprecated Endpoints: The current authorization API endpoints (https://api.dronetag.app/v1/auth/*) are now deprecated. You must migrate to the new service (https://auth.dronetag.app).
• OAuth 2.0 Credentials: Sign-in will now require OAuth 2.0 application credentials. Until automated OAuth 2.0 management is available, credentials will be issued manually.

Migration Timeline​

• By the End of February 2025: Legacy authorization endpoints will be fully removed. All authorization requests must be migrated to the new service.

Step-by-Step Migration​

1. Use an OpenID Connect (OIDC) Library (Recommended)​

To simplify the transition, we recommend using an existing OIDC library for OAuth 2.0. These libraries manage the OAuth 2.0 flow, handling access tokens, refresh tokens, and other OIDC-related tasks.

You can find a list of certified OIDC implementations here: OpenID Connect Certified Libraries.

2. Migrate Authorization Requests to the New Auth Service​

All authorization requests must be migrated to the new endpoint:

• Old Endpoint: POST https://api.dronetag.app/v1/auth/jwt/token
• New Endpoint: POST https://auth.dronetag.app/realms/master/protocol/openid-connect/token

Ensure you update your request logic to point to the new URL and expect a different JSON response structure. The new response includes access_token and refresh_token fields, in addition to other fields.