Get the Driver List

The Get the Driver List API call retrieves the current Driver List stored on a device. Use this when you want to confirm which Driver ID codes are currently loaded, validate that a previous update was applied, or inspect the active list before sending a new one.

This is commonly used as part of a broader Driver ID and immobilisation workflow. Depending on device configuration, the device may require a valid Driver ID before the asset can be started, or may only toggle its output when a valid Driver ID is presented. For the wider workflow, see Driver ID and Immobilization with Powered Devices.

This call returns the Driver List currently stored on the device, including the selected layout and each driver entry. Each entry may include the ID type, encoded ID data, name field, and flags value used by the device.
 

Request Format

Send a GET request to the endpoint below, replacing <deviceserial> with the target device serial number.

https://api.oemserver.com/v1.0/driverlist/get/<deviceserial>

For example, to retrieve the Driver List from device 123456:

https://api.oemserver.com/v1.0/driverlist/get/123456

The request uses Basic Authentication in the same way as other OEM/Device Manager API calls.
 

Example cURL

curl -X GET 'https://api.oemserver.com/v1.0/driverlist/get/310056' -H 'Authorization: Basic <user/pass>' --data-raw ''

In this example, the request asks device 310056 for its currently stored Driver List.
 

Response

{"Layout":0,"Drivers":[{"IdType":7,"IdData":"FBI0UAAA","Name":null,"Flags":1}]}

The response contains the Driver List currently stored on the device.
 

Response Fields

• Layout - the Driver List layout currently in use on the device.
   
• Drivers - an array of driver entries currently stored on the device.
   
• IdType - the driver identifier type. Common values are 1 = DMRFID, 2 = iButton, and 7 = Wiegand.
   
• IdData - the encoded identifier value stored for that driver.
   
• Name - the stored driver name, if the selected layout supports names. This may be null if no name is stored.
   
• Flags - the flags value associated with that driver entry.

In the sample response above, the device is using layout 0 and has one stored driver entry with an IdType of 7, which indicates a Wiegand credential.
 

How to Interpret the Result

This endpoint is useful for confirming what the device will currently accept as valid Driver IDs. It is often used before or after a Set the Driver List request so you can compare the intended list with the list actually stored on the device.

If the returned list is shorter than expected, the device may have reached the storage limit for the selected layout. The maximum number of stored drivers depends on the configured layout and the memory allocated for the Driver List on the device.
 

Related Notes

The format of IdData depends on the reader type being used. If you are choosing a reader type or validating tag data, see Driver ID Options.

Next Steps

To update the list stored on a device, see Set the Driver List. For the broader installation and immobilisation workflow, see Driver ID and Immobilization with Powered Devices. To compare supported reader and tag types, see Driver ID Options.

Further Reading

• Driver ID and Immobilization with Powered Devices
   
• Driver ID Options