Stream locations and markers via webhooks
Use webhooks to ingest live location as well as activity, outage, trip, geotag, and geofence markers generated by your devices from HyperTrack to your server end point. This can allow you to implement real-time application workflows on your server.
Use status updates and markers to power your application workflows
Your webhook integration with HyperTrack can empower you to handle application workflows on your server in real-time as soon as your app user's devices generate location data. You can ingest the following webhook updates posted to your server:
- Activity transitions
- Outage notitications when devices are not tracking
- Geotags generated by your app users
- Trip status for ongoing trips
- Geofence markers as visits take place
- Location updates for your app users on the move
- Nearby API request completion to be notified about Nearby API request results
Activity transitions
The device is actively sending updates. In that case, the device_status.data object is provided with an activity property. It can be one of stop, walk, or drive.
note
Run and cycle activities are purposefully removed because fewer businesses cared about it, and inaccurate classification obfuscated walks and drives. We are working on adding public transit detection, including trains, ferries and buses.
Understanding device status
The device_status object has properties that are conditional to device_status.value.
It can be one of the following: active, inactive or disconnected. See here for a detailed description.
Device status changes include device becoming active, inactive/disconnected and activity transistions such as start of walk, drive, or stop.
Device status provides update about the device. The value can be active, inactive and disconnected. Please read here to understand how HyperTrack tracks device status.
Mobile devices send health data through the Mobile SDKs. The data is showing tracking outages and resumptions. Health data is available for outage events when an outage affects location data. This data is sent with a low frequency (based on device activity).
When the device is active, we include the activity when available. Mobile phones use a variety of sensors combined with location data to intelligently identify phone users’ activity. Activity transitions are sent with a medium frequency (similar to summary events).
HyperTrack supports 3 types of activity transitions: walk, drive, and stop.
For your convenience, we provide you a set of free-to-use SVG icons to display activities in your application.
Outage notifications
Inactive device status
The device is not sending location updates and in that case, the device_status.data object is contains reason property`. These reasons can be one of the following below:
airplane_mode_detectedlocation_permissions_deniedlocation_services_disabledlow_batterymotion_activity_permissions_deniedmotion_activity_services_disabledmotion_activity_services_unavailablepush_token_missing_to_start_trackingtracking_stoppedtracking_service_terminateddeleteduninstalledlocation_unavailablelocation_unavailable_battery_saverlocation_unavailable_provisional_authorizationsdk_killed_low_memorysdk_killed_by_usersdk_killed_by_app_updatesdk_killed_by_permissions_activitysdk_killed_by_permissions_locationsdk_killed_by_os_updatesdk_killed_by_os_rebootsdk_killed_by_low_powerstorage_unavailablenetwork_limit_reachedlocation_permission_asked_in_backgroundlocation_permission_restrictedmotion_activity_permission_not_determinedmotion_activity_permission_asked_in_backgroundlocation_permission_not_determined
Note that this is an embeddable dashboard view that you can implement in minutes for your ops managers as explained in this guide.
Disconnected device status
Connection with the device was lost unexpectedly (no data received for over an hour). In that case, the device_status.data object is empty.
Geotags
Geotags are generated when your app users take action in the app as described in the track work day with geotags guide as well as in track actual distance between geotags guide.
Integrate geotags in real-time with your app backend via webhooks
If your app business workflow requires real-time integration of app user's notes as they take place, please review an example payload as shown below.
You can see that not only you get back payload data your app user generated from the mobile app, but also route_to data which contain distance in meters, duration in seconds, start_location from the previous geotag event for which distance and duration is generated, as well as recorded_at timestamp which captures the time this app event was received from your user's app.
Plus, you get location that HyperTrack captures for you when your app user generates a note in the app.
Get geotag distances in real-time via webhooks
Please review an example payload as shown below.
You can see that not only you get back payload data your app user generated from the mobile app, but also route_to data which contain distance in meters, duration in seconds, start_location from the previous app event for which distance and duration is generated, as well as recorded_at timestamp which captures the time this app event was received from your mobile app.
Lastly, but not least importantly, you get location that HyperTrack captures for you when your app user generates an app event.
Trip status
In your business workflow, you may need to take actions depending on the status of the trip you created for your app user. HyperTrack provides real-time updates for your app that deliver to you important events associated with your trip.
Trip events are posted whenever a trip is started, a specified device enters or exits the destination, a trip with a scheduled arrival is estimated to be delayed, and when a trip is completed. Events provide the device triggering the event, the trip, event type (create, destination enter, destination exit, delay, or completion), and trip metadata defined during start.
Currently, HyperTrack will send notifications triggered by:
- Trip start: For every new trip, start events are posted.
- Destination arrival: Trips destination arrival events are posted when devices enter a specified destination.
- Destination exit: Same as arrival events, but posted when devices exit the specified destination.
- ETA changes: As trip progresses it provides you real-time ETA changes
- Trip delays:Trip delay events are posed for trips with a scheduled arrival time. Delay events are send as soon as the estimated time of arrival is past the scheduled time.
- Trip completion: For every completed trip, completion events are posted.
All trip updates will include the update type, created_at, device_id, trip_id and trip_metadata at the very least.
It is up to you to decide how to utilize trip updates. To give you an idea, the following can be done:
- complete trips based on custom logic
- update database records of trips
- send mobile device notifications
- update real-time views and maps
- start custom processes (training of AI models, send custom emails, etc)
Trigger notifications based on trip activity
A common use case is to leverage trip events to trigger contextual, location-aware notifications in web or native applications. To make these types of notifications possible, you should maintain a list of devices (users), a list of trips, and notification templates for trips events (start, destination enter/exit, completion) to be used as notification message.
It is suggested to leverage device metadata that can be set either through mobile SDKs or through Devices API in combination with trips metadata to establish all relevant information in order to send highly contextualized notifications.
More context is provided based on the update type. Please take a look at the trip webhooks references for more details.
Trip start
Please see an example for the trip start webhook payload. Once the trip is created, you may be able to get Trips API to receive trip estimate and expected route to the destination.
Trip destination arrival
The payload below is an example of the trip destination arrival, as denoted by destination_arrival value field inside data object.
Trip destination exit
The payload below is an example of the trip destination exit, as denoted by destination_exit value field inside data object.
The data object has the arrival/exit locations and the duration the user stayed at the destination.
Note exit location may be empty when the marker was closed due to an outage event.
Trip ETA change
In a business operations workflow, you may have more than one trip with destination and ETA scheduled for today for a given app user. For example, your app user may be a service technician visiting multiple sites for the day or grocery delivery driver who has a number of drop off locations to visit.
To help understand which trip is most relevant to your customer as your app user is on the route, HyperTrack provides an ETA change via a new webhook for your ongoing trips.
This webhook payload has eta_change inside its value field. You will get this real-time webhook update for all of your trips with destination each time ETA is updated.
The payload below is an example of a trip ETA change, as denoted by remaining_duration and remaining_distance inside data object.
You may be able to use these values to determine when to start notifying your customers and also share real-time locations of your service workers.
Trip delay
As explained below you may specify when your app user is expected to reach a destination for your scheduled trip. In case if there is a delay, you will get a webhook update with this payload below. Note that value inside data object is delayed and arrive_at shows the new expected arrival time for your app user.
If the trip gets delayed further, you will receive additional updates via this trip delay webhook until the trip is completed.
Geofence markers
HyperTrack provides the capability to send you geofence visit markers from your HyperTrack SDK integration.
Webhook payload is following this data structure:
In the example, you can see that device_id with value 321E4567-AAAA-12D3-A456-42661417400 exited the geofence with geofence_id fed594a1-10c7-47e3-8aa3-f5fcaa265bdb.
For further reference, you may visit this guide to receive and process geofence visit events.
Location updates
Location time series data where each location in the stream includes coordinates and the optional fields speed, altitude, bearing, and accuracy when available.
Location events are sent with a high frequency (~ 100x more than activity events).
- Data: Current location of the device in GeoJSON format. Altitude, the optional third parameter in the coordinates array, is the current device elevation in meters, relative to the sea level on iOS and relative to the WGS 84 reference ellipsoid on Android.
- Location Accuracy (Optional): The estimated horizontal accuracy of the location, radial, in meters. When the location identifies the center of a confidence circle, the accuracy defines the radius of the circle (in meters). For Android, there is a 68% probability that the true location is inside the circle.
- Bearing (Optional): The horizontal direction of travel, measured in degrees and relative to true North. Degrees start at true North and continue clockwise around the compass (north is 0, east is 90, south is 180, west is 270 degrees).
- Speed (Optional): Speed of travel in meters per second.
Use the location object to display the location of a device on a map. It is important to understand the GeoJSON format to handle the data correctly:
- Type can only be "Point" in this scenario
- Coordinates is an array of 2-3 values (the last being optional) with the following format: [longitude, latitude, altitude]
The accuracy value is often used to draw a "halo effect" around the location dot with the accuracy (in meters) value being the radius of the surrounding ring. In addition, bearing (in degrees starting at due north) is used to draw a directional indicator at the location dot.
Battery status changes
Battery status changes include values such as low, normal and charging
Device objects contain a battery property to indicate the state of the device battery. The property can take one of the following values: low, normal, or charging
tip
If you would like to receive battery state updates as they come in, it is recommended to use battery updates webhooks. This enables reacting to low battery risks as they happen.
HyperTrack sends battery updates to indicate the battery health. These events include details on charge, discharge and low battery.
info
Battery updates can be combined with outages as a leading indicator for tracking outages.
Identifying devices by name and metadata in webhook payloads
Optionally, webhook payload can also contain name and metadata associated with the device as shown in the example below with name and metadata keys.
note
Device name and metadata addition to webhook payloads is in limited Beta with select customers. Please contact us to get access.
Nearby API request completion
In addition to GET /devices/nearby API, you will also get notified about the completion of a request via webhook notification with below payload example structure. To see how Nearby API works, please see this guide.
Notification payload for Nearby API completion will look like this:
Webhooks setup
To get started with webhook integration, the HyperTrack dashboard allows you add your webhook URL on the Setup page.
Just enter your webhook URL and click on Add Webhook. Once entered, it will immediately change to Receiving markers and location update if Include location updates option is selected.
important
If you select to receive location updates from devices in your account, it will increase number of webhooks by 10-40x. Please use this option only if your business use case requires real-time location update stream from all locations from all tracked devices.
You may be able to opt-in later to receive location updates should your requirements change. Please note it takes up to 10 minutes for your configuration changes to take effect.
Validate webhook notifications
Your webhook payload can be validated to confirm as being sent by HyperTrack.
All webhook payloads sent to your server contain x-hypertrack-signature header. This header is an HMAC-SHA1 signature generated using your webhook request payload and your account's secret key. Your secret key can be found in your account's dashboard setup page as SecretKey.
Please review code examples below for guidance on how to perform signature verification.
- NodeJS
- Python
Troubleshooting webhook integration
Please review common issues below for suggestions on how to resolve them.
Webhooks payloads are not sent to your server
To confirm if your webhook server is working as expected, you may send a test event by clicking on three dots on the webhook setup screen and and then clicking on Send test event option.
You will receive a webhook test payload that will be like this:
If you have not received the request, then you may want to verify if your server is reachable by making a POST request with a tool of your choice to your webhook server URL. Otherwise, your server will be receiving webhooks from HyperTrack once devices under your account generate location data.
note
You will likely not receive webhooks right away. We offer the capability to send test events (upon click on the three dots on the screen above). This will allow you to test your implementation.
Multiple webhook payloads received for the same event
When you observe multiple webhook payloads received for the same event, for example, a trip completion event, you need to check if your URL end point returns a successful and timely response for each webhook HTTP POST request sent to your server.
Otherwise, HyperTrack will attempt to re-send the same request up to three times before giving up.
Questions?
If you would like to get help with location tracking needs for your app users' devices, questions or comments on any of the topics above, please do not hesitate to contact us.