Data Connections

Feature Summary

The Data Connections feature in GSatTrack enables users to integrate and connect their asset-tracking data with external systems and applications. This functionality enhances data interoperability, allowing organizations to streamline operations, improve analytics, and make informed decisions based on comprehensive data insights.

Overview

The Data Connections feature is designed to facilitate seamless communication between GSatTrack and other third-party applications, services, or platforms. By establishing these connections, users can automate data exchange, synchronize information, and enhance their asset management capabilities. This feature is particularly beneficial for organizations that utilize multiple software solutions and require cohesive data management across platforms.

How to Use

How-To: Add Data Connections

1. In the “Navigation” Menu select the “Manage” icon.

2. Select “Data Connections”

3. Click on “+ Add Data Connection”

4. Fill in the required information:

5. Name

6. Type - The type of connection

7. Select which Assets/Asset Groups the connection applies to and excludes from.

8. Click on the “Create Data Connection” button.

How-To: Edit Data Connections

1. In the “Navigation” Menu select the “Manage” icon.
2. Select “Data Connections”
3. Click on the “Edit” button next to the desired Data Connection.
4. Make the desired changes
5. Select the “Save Changes” button.

How-To: Re-enable a Suspended Data Connection

A Data Connection that has been failing continuously is suspended automatically — see “Suspension” under Delivery and Reliability below. Restoring it is a deliberate, manual step:

1. Fix the underlying problem at the destination — expired credentials, an expired TLS certificate, a decommissioned host, or a changed URL.
2. In the “Navigation” Menu select the “Manage” icon.
3. Select “Data Connections”
4. Find the connection marked “Suspended” in the Status column.
5. Click the “Re-enable” button next to it.

Delivery resumes with new data from that point onward. Nothing from the outage is recovered — re-enabling is not a catch-up:

• Positions and events that arrived while the connection was suspended were never queued, so there is nothing to resend.
• Anything still waiting in the queue when the connection was suspended is discarded rather than held, and does not appear in the connection's log.

If you need the data that was missed, retrieve it from the portal directly — for example with a Position report over the affected period — rather than expecting the connection to backfill it.

How-To: Get Notified When a Data Connection Is Suspended

1. In the “Navigation” Menu select the “Manage” icon.
2. Select “Data Connections”
3. Click the “Notify when suspended” button at the top of the page.
4. Enter one or more email addresses, and/or click “Choose Contacts” to select existing Contacts.
5. Click “Enable”.

Contacts receive the notification in their own language and timezone. To stop the notifications later, reopen the same panel and click “Disable”.

Additional Information

Data Connection Types

These data types enhance the functionality of GSatTrack, enabling users to create a comprehensive view of their assets and make informed decisions based on real-time and historical data.

• URL: Sends each position or event as an HTTP GET to a web address you define, with values such as the asset identifier, latitude, longitude, timestamp, speed, and heading substituted into the URL. This is the classic webhook pattern, and it suits automation platforms, lightweight internal endpoints, and middleware that expects query-string parameters rather than a request body.

• JSON: JavaScript Object Notation (JSON) is a lightweight data-interchange format that is easy for humans to read and write. In GSatTrack, JSON is used to transmit structured data, making it ideal for exchanging information between GSatTrack and other systems, such as asset details, status updates, and configuration settings.

• NMEA: The National Marine Electronics Association (NMEA) format is primarily used for marine navigation data. GSatTrack utilizes NMEA data to receive real-time positioning information from GPS devices, which is crucial for tracking the location and movement of assets, particularly in maritime contexts. The NMEA data connection relays each position to the configured destination — a host or IP address and port — as an NMEA sentence over UDP.

• SPOT Data Push: Sends position and status data out to a destination you nominate, using exactly the same XML format that the Globalstar SPOT Data Push produces. Its purpose is compatibility: if you already have a system built against the SPOT feed from your SPOT My Account, you can point this connection at that system and it will keep working without any changes on the receiving end — the payload, schema, and message types are identical. Deliveries carry the standard SPOT message types, including TRACK, OK, NEWMOVEMENT, STOP, POWER-OFF, 911, and 911-CANCEL, and are authenticated with the customer and secret token your receiving system expects. Because the format is applied to whichever assets the connection covers, you can also deliver data from non-SPOT hardware to a system that only understands the SPOT format.

• Gundi Sensors: Gundi sensors provide environmental and operational data related to tracked assets. This data can include temperature, humidity, and other sensor readings, allowing users to monitor asset conditions and ensure compliance with operational standards.

• Movebank: Movebank is a data management platform for tracking animal movements. In GSatTrack, integration with Movebank allows users to access and analyze wildlife tracking data, supporting research and conservation efforts by providing insights into animal behavior and migration patterns.

Delivery and Reliability

Data Connections do not deliver on a best-effort basis. Every position or event that matches a connection is placed on a durable delivery queue at the moment it is stored, and it stays queued until your destination accepts it or the portal gives up. A destination that is briefly busy, restarting, or unreachable does not cost you data.

Delivery order and multiple destinations

Deliveries to a given destination are sent oldest-first, one at a time, so a receiving system that expects data in chronological order gets it that way.

When a Data Connection has more than one destination URL, each destination is delivered independently. A destination that is down or slow does not hold up the others on the same connection, and does not slow the rate at which they receive data.

Retries

When a destination returns an error or fails to respond, the delivery is retried automatically on a widening schedule: 15 seconds after the first failure, then 30 seconds, 1 minute, 2 minutes, 4 minutes, and so on — doubling each time up to a maximum of one hour between attempts, then hourly from there.

Each attempt gives the destination 15 seconds to respond before it counts as a failure.

A destination that is briefly unavailable therefore catches up on its own, with no data lost and no action needed from you.

What your endpoint should return

If you are building the system that receives a URL or JSON Data Connection, this is the most important thing to know:

An error response does not mean "skip this one". It means send this exact data again after the next retry interval. If your endpoint rejects a message for a reason that will never change — data that fails your validation, an asset you do not recognise, a record you already have, or a fault in your own processing — then every retry produces the same rejection.

That situation is costly, because deliveries to a destination are sent strictly in order. A message that can never succeed sits at the front of the queue and holds up everything behind it:

1. It is retried for 24 hours, and the same rejection comes back every time.
2. Nothing else for that destination is delivered while it is stuck at the front.
3. After 24 hours it is abandoned and the queue moves on — but positions and events that piled up behind it have been aging that whole time, and any that passed their own 24-hour limit are abandoned too, without ever being sent.
4. Those abandoned deliveries, with no successes to offset them, are exactly what triggers suspension.

One permanently-rejected message can therefore cost you up to a full day of data for that destination and leave the connection suspended.

In practice:

• Accept the data, return success straight away, then validate and process it on your side.
• Use an error response only for genuinely temporary problems — your service restarting, a dependency being unavailable, or a rate limit — where the same data would succeed if sent again shortly. The automatic retries are designed for exactly this.
• Do not use HTTP status codes to signal business decisions. "I don't recognise this asset" should be a success response and a note in your own logs, not a 400.
• Respond within 15 seconds. If your processing takes longer, acknowledge first and do the work asynchronously.

This applies to Data Connections delivered over HTTP, such as URL and JSON. It does not apply to NMEA, which is sent over UDP with no response and is therefore never retried.

When the portal gives up

An individual position or event is abandoned if it has not been delivered within 24 hours of being queued. Abandoned deliveries are recorded in the connection's log, so you can see exactly what was not delivered and why.

In practice: a destination that recovers within 24 hours receives everything that queued up during the outage. An outage that runs longer than 24 hours loses the oldest data as it ages out.

Suspension

If a Data Connection accumulates at least 10 abandoned deliveries and not one successful delivery across a 72-hour period, the portal suspends it.

Both conditions have to be met. A connection that fails frequently but still succeeds sometimes is never suspended — suspension is reserved for integrations that are wholly dead, such as one pointing at a decommissioned host or using credentials that no longer work.

A suspended connection stops queueing new deliveries entirely, which keeps a long-broken integration from consuming delivery capacity that your working connections need.

The Status column on the Data Connections page shows where each connection stands:

Suspension is never automatic in reverse: a suspended connection stays suspended until someone re-enables it.

See Also

• Manage

• Assets