Our API v2 is here!
Since starting our private beta in December 2015, we have interacted with over 60 companies interested in using HyperTrack. This gave us a better and deeper understanding of their tracking needs and how it is currently being met. We learned use cases that we had not anticipated in our first version of the API. Let me illustrate with a few examples.
A hyperlocal logistics company helps local merchants deliver to customers. The merchant uses an app to book a runner, then tracks the runner as he is on the way for the pickup. Details of orders are often keyed in after the runner reaches the shop. As the runner is on the way to make multiple deliveries, the merchant wants to track progress in the app as well as provide end customers a link to track the delivery in real time. Throughout this process, the logistics company wants to remain alerted about things running late, runners missing a pickup, or going offline. There is a need to track on-time performance of runners to enable a scorecard and incentives.
An ecommerce logistics company sends a text message to customers when the field executive leaves the hub with the packets. The text notifications help reduce the returns because customers anticipate the delivery. They want to add a link for customers to track the executive in real time with an ETA and a way to call them if needed. The company wants to test if this brings down returns further and gives their service an edge over competitors.
A food delivery company with a central kitchen dispatches drivers with several orders at a time. They know when the orders are dispatched from the kitchen and when the driver returns, but everything in between remains a black hole. They want customers to see the driver on a map only when they are the next delivery. Otherwise, they want the customer to see the ETA only and not the map. The company wants to be able to track all historical trips and replay them in order to monitor the driver’s performance.
A local taxi service wants their customers to be able to track their taxi on a map just like leading taxi app companies, with turn by turn status on a map and accurate ETAs. Once the customer is in the taxi, they want the ability to send a link to friends and family so they can track the ride in real time through their browser. The live tracking needs to be accompanied with a banner to download the app so it leads to viral marketing.
An intra-city bus service for daily commuters has a fixed route with a set timetable for each stop. They want to improve the ETA for customers to track the buses. They want to monitor on-time performance of buses, which seem to have a different ETA than four-wheelers or two-wheelers that their existing solution uses.
In all examples, the companies have apps that their drivers use to mark the start and end of a trip, and the various points along the route. They start with the approach of getting raw location streams for the smartphone GPS data points through the driver’s app, and use a brute force method to render these streams for their customers and store these points in logs for future analysis.
The first version of our APIs allowed multiple deliveries in a trip, with battery & data optimized data streams and filters to smoothen out the movement. The API generated ETAs and unique tracking links per order that could be used in an app or through the browser. In API V2, we allow trips to have pickups in addition to deliveries. Each stop on the route is allowed pickups and deliveries of multiple orders. The API allows users to post changes to the sequence of orders. We have added webhooks for more status changes. The ETAs automatically account for check-out time before the driver is en route and then check-in time after the driver arrives at the destination. Trips need not begin or end at a hub, neither do they need to include a hub at all.
Let me briefly walk through how to integrate with API v2. You will create drivers on our APIs and optionally assign them to fleets. When a customer places an order, you will create a pickup or delivery task at a destination. The starting point or pickup point of trips for a fleet may be marked as a hub. The driver starts a trip in the app for the pickup and delivery tasks, then marks them done as they are completed. These start and done events need to be posted to our APIs. The API returns ETAs for each task at the start of the trip and continues to update them as the trip progresses. We fire events as webhooks as the tasks within a trip change statuses. For example, you will receive the task.arriving event when the driver is within 2 minutes of arriving, and the task.delayed event when the driver is getting delayed. These events may be used to fire alerts to your customers or ops team. A trip summary is generated with distance travelled, time taken and route polyline. This summary may be provided to the end customer and will be permanently available to view on your HyperTrack dashboard.
Click here to request access to the new APIs.
