GPS Tracking API with Individual Keys for Subusers

Connecting a GPS tracking platform to external applications requires independent credentials, clear permissions, and responses that development teams can process. This Secure GPS update moves API key management to My Account, lets each subuser generate an individual key, and limits access to devices assigned by the account administrator.

The same update expands the public API so an application can authenticate with that key, list authorized devices, retrieve one device, obtain its latest location, and query locations or alerts for a period. A company can connect Secure GPS to dashboards, operational applications, or analysis workflows without sharing the primary password or exposing the entire fleet.

Individual API keys managed from My Account

An API key is a credential used to identify an integration. In Secure GPS, key management moves from general settings to My Account, associating it with the user who will make the connection.

Each subuser can generate an individual key. When that subuser calls the API, the scope follows the administrator's assignments: only authorized and enabled devices are available. This applies the same limited-access principle used in daily account operations.

What problem this solves

Sharing one key across several applications or people makes access harder to remove when a supplier, employee, or process changes. Individual keys separate responsibilities. The administrator can assign only the required vehicles to a subuser, while the integration uses a credential that does not expose the account's interactive password.

A real-world integration

A logistics company can create a subuser for the team building its delivery dashboard and assign only distribution vehicles. The application receives its own key, queries those devices, and cannot access assets assigned to other departments. When the project ends, the company can revoke the key or remove device assignments without changing credentials for other users.

API authentication with username and API key

The API adds an authentication flow that accepts a username and API key. When the credentials are valid, Secure GPS returns a temporary token used to authorize later requests.

In this release, the authentication contract is:

• POST /api/Auth/Token
• JSON body with required UserName and APIKey fields.
• Successful response with Success, Token, and Expires.
• The issued token is valid for 24 hours in this version.
• Invalid credentials return an authorization failure; incomplete or invalid requests use the API error format.

The token must be sent as the authorization credential for protected routes. An integration should request a new token after expiration, keep the API key out of public applications, and transmit credentials only over secure connections.

List devices available to a subuser

GET /api/devices returns the devices authorized for the authenticated user. This route supports device selectors, operational catalog synchronization, and discovery of identifiers that can be used in later queries.

Each item can include Id, Name, Description, MIN, Tags, and Expires. The response uses Devices for the collection. Content depends on the data available for each tracker and the assignments made by the administrator.

GET /api/device/{deviceId} retrieves one device within the same scope. If the identifier does not exist, is not enabled, or is not assigned to the subuser, the API rejects the request.

Query the latest GPS tracker location

GET /api/device/{deviceId}/LastLocation returns the latest valid location found for an authorized device. The response uses LastLocation and can include date, latitude, longitude, and additional values sent by the tracker.

This resource can place a vehicle on an external dashboard or help an operational application review the last known position before assigning work. “Latest location” means the most recent data available to the query, not a guarantee that the tracker is connected at that moment. The application should inspect the record date to evaluate freshness.

Retrieve locations for a time period

POST /api/device/{deviceId}/Locations accepts a JSON body with required From and To fields. In this version, each request supports a maximum interval of 60 minutes.

The response contains a Locations collection. Depending on data supplied by the tracker, a location can include:

• DateTime, Latitude, and Longitude.
• Speed, Course, Battery, and InactiveSeconds.
• Fuel, Fuel2, Temperature, and RPM.
• SensorTime1 through SensorTime4, Milleage, and Attributes when available.

Optional fields should not be assumed for every model. Integrations need to accept null values, follow documented or configured units, and validate behavior with the actual tracker.

Query GPS alerts through the API

POST /api/device/{deviceId}/Alerts retrieves alerts for a device during a period. The body requires From and To, accepts AlertName as an optional filter, and keeps the 60-minute maximum interval for this version.

The Alerts collection can include DateTime, Latitude, Longitude, Text, email or SMS notification indicators, and an Alerts list containing detected types. An external application can associate each event with a location and present an operational history.

Alert names must match values supported by the contract. Applications should handle unknown types tolerantly so a new Secure GPS condition does not break existing processing.

Response format, errors, and limits

Responses share Success and Error fields in addition to the object or collection for each route. Valid requests return normally; incomplete data, unauthorized devices, or invalid periods return request errors; and an unexpected failure uses a service error response.

The API applies usage limits and can return an error after allowed capacity is reached. Integrations should avoid unnecessary repeated calls, retry with delay, log errors without credentials, and divide long periods into supported intervals.

Best practices for integrating the Secure GPS API

1. Create a dedicated subuser for every integration or clearly separate responsibility.
2. Assign only the required devices and review assignments periodically.
3. Generate the key in My Account and keep it in a secret store, never in public code, screenshots, URLs, or logs.
4. Request a token with UserName and APIKey, retain it only for its valid lifetime, and renew it after expiration.
5. Validate GET /api/devices first and use only identifiers returned for that user.
6. Handle optional fields, error responses, usage limits, and maximum periods without assuming that every tracker supplies identical data.
7. Revoke or regenerate the key when ownership changes, an integration ends, or exposure is suspected.

Public technical summary

• An API key is generated and revoked from My Account and belongs to the user managing it.
• Subusers can have individual keys whose access is limited to assigned devices.
• Authentication uses POST /api/Auth/Token with UserName and APIKey.
• The API exposes routes to list devices, retrieve one device, obtain its latest location, and query locations or alerts.
• Historical location and alert requests support periods up to 60 minutes in this release.
• Routes, fields, and limits described here belong to this historical version; a new integration should compare them with the current public Secure GPS documentation.

This update makes the Secure GPS API a more controlled option for GPS tracking integrations: every process uses its own identity, follows authorized device assignments, and receives structured data without sharing the account's primary credentials.