Introduction

Worker in HyperTrack is the Driver/Expert/Pro/Talent/Courier. Every worker has a worker_handle which you use internally to identify your mobile app users. For example, this could be the user_id, email, phone number etc.

The worker_handle stays the same while the devices (device_ids) used by the worker might change over time. It is used in the Ops Views to display information about the work done by the worker.

How to link a Worker's device?

Set the worker handle on each login and launch of your app:

• native iOS / Android: HyperTrack.workerHandle = user_id
• on cross platform (JS): HyperTrack.setWorkerHandle(user_id)

That's it! The device is now linked to the worker. Go to the HyperTrack dashboard Workers page and search for the linked user_id.

On logout set the worker handle to an empty string "" value to indicate that the device should be unlinked from the worker.

Legacy device metadata linking method

In the past we've supported worker device linking by setting the device metadata with a driver_handle or worker_handle key value pair. This method is now deprecated. You should use the dedicated method/property as instructed above.

Migrating from Devices to Workers

Where previously you would rely on device_id you now can use worker_handle. This lets you use the same identifier you identify your app's users with, inside HyperTrack.

In the past you'd use the device_id (ephemeral) to know which worker to start tracking for. With new worker device linking, you can ditch the device_id and only use the worker_handle (constant).

For example, let’s say John has a device A. Tomorrow he switches to device B. Earlier, you would have to update the John’s linked device_id on your end from A to B to ensure that you start tracking the right device.

With Workers you can forget about juggling the device_ids and instead use the worker_handle for all of your location tracking workflows.

Workers API is the next step for Devices API (deprecated), it supersedes it. Its ergonomics allow for more flexibility, like tracking a worker's order across multiple devices, or retrieving a complete history of a worker who’s just recently changed his device.

It also opens up the possibility for shedding some of the current complexity of maintaining the device-worker mapping by your backend.

On the server

Workers are a high level construct you can use to interact with our APIs:

• Worker webhooks will deliver device agnostic updates as workers switch from one device to another.
• Worker timelines return events that seamlessly weave multiple device events in one place:
  • Get worker timeline via GET https://v3.api.hypertrack.com/workers/{worker_handle}.
• You can now manage the worker availability and schedule to enable automatic start/stop tracking and order planning.
  • Set worker availability and schedule via PATCH https://v3.api.hypertrack.com/workers/{worker_handle}.
• Nearby search can be used to find available workers for work.

Ops Visibility

Ops teams can view worker device linking using the Order Profile Ops View and the Worker Profile Ops View.