WorkWave Route Manager (WWRM) exposes its data via an Application Programming Interface (API). This document is the official reference for that functionality.
Throughout this document it is assumed that the reader is well acquainted with the WorkWave Route Manager Web Application, its features and terminology.
The API is entirely HTTP-based
Methods to retrieve data from the API require a GET request. Methods that submit or change data require a POST. Methods that destroy data require a DELETE. API Methods that require a particular HTTP method will return an error if you do not make your request with the correct one. HTTP Response Codes are meaningful.
The API is a RESTful resource
The API attempts to conform to the design principles of Representational State Transfer (REST). More details on REST can be found here. Libraries to build REST-compatible API clients are readily available for several programming languages. A list of REST frameworks is available at the bottom of the above mentioned page.
The format used for structured data exchange is JSON
SSL/TLS is supported (and highly recommended)
The API works with both plain HTTP and HTTP-within-SSL/TLS (HTTPS). HTTPS is highly recommended to avoid passing both the authentication KEY and potentially confidential data (e.g.: clients’ names and addresses) in clear text over the web.
Parameters have certain expectations
Some API methods take optional or requisite parameters. Please keep in mind that all query-string parameter values should be converted to UTF-8 and URL encoded.
Authentication is performed using an API key provided by WorkWave. The API key must be included in the HTTP(S) request using one of the following two methods:
via the key query-string parameter via the X-WorkWave-Key HTTP header X-Fleet-Key is still supported for backward compatibility Where both are provided the query-string parameter takes precedence.
The API key is a string, more specifically it is a UUID in its canonical form (e.g.: “123e4567-e89b-12d3-a456-426655440000”).