Legacy Worker Device Linking

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:

Ops Visibility

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