Welcome to lessor.api.stg.rob-net.nl

This page is your starting point for connecting to the ROB-Net REST API for lessors. Here you can find information about the ins and outs of using the REST API. Use the sidebar navigation to jump to a specific topic.

Use the navigation bar at the top right of this page to open the changelog and error codes, or to view the OpenAPI specification on the API Details page.

API Overview

The ROB-Net REST API allows lessors to register and maintain their vehicles in ROB-Net. With it you can create, update and remove vehicles, and keep their related data — such as tires, mileage and maintenance — up to date. The current specifications and schema can be found on the API Details page.

Authentication

The REST API uses machine-to-machine (M2M) authentication based on the OAuth 2.0 Client Credentials grant. This flow is designed for server-to-server communication where your software authenticates as itself, without any human user being involved. No interactive login or user consent is required.

Before you can connect, ROB-Net provides you with a unique client_id and client_secret. Treat the client_secret as a password: store it securely, never expose it in client-side code or public repositories, and rotate it if you suspect it has been compromised.

Requesting an access token

Exchange your credentials for an access token by sending a POST request to the token endpoint with a body of type application/x-www-form-urlencoded: 


POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
A successful response returns a signed JWT access token together with its lifetime, expressed in seconds: 

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...",
    "token_type": "Bearer",
    "expires_in": 3600
}

Calling the API

Include the access token in the Authorization header of every request, prefixed with Bearer as follows: 


Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9...
Note that the actual token is much longer than the example above.

Token lifetime

Access tokens are short-lived (see expires_in). Cache and reuse the same token for the duration of its validity instead of requesting a new one for every call, and request a fresh token shortly before the current one expires. Requests made with a missing, malformed or expired token are rejected with an HTTP 401 Unauthorized response.

Encoding

The REST API exclusively uses UTF-8 for HTTP requests.

Date and DateTime

All dates are expected to be in the format yyyy-MM-dd (e.g. 2026-06-23), commonly known as an ISO 8601 format and described as a full-date by RFC3339 on internet Date/Time formats. The fields using dates as value will be documented in the API Details as having the format date.

The datetime values are expected to be in the format yyyy-MM-ddThh:mm:ssZ (e.g. 2026-06-23T07:30:00Z), also known as an ISO 8601 format and described as a date-time by RFC3339 on internet Date/Time formats. The fields using datetime as value will be documented in the API Details as having the format date-time. In addition, it is allowed to replace the trailing Z with a time zone offset, e.g. +02:00 for the GMT+2 time zone which is the daylight saving time for the Netherlands.

Note that all API responses which include datetime values will always use the UTC time zone, e.g. "checkoutDate": "2026-06-23T06:00:00.000Z", regardless of the time zone the datetime was originally supplied with.

Workflow

Updating vehicle data

The Lessor API lets you keep the vehicle data (objects) in ROB-Net up to date with your own system. You push changes to ROB-Net as they happen on your side, keyed on the vehicle's licensePlate. Data flows in one direction only: from your system into ROB-Net. The API is not intended for bulk queries: there is no endpoint to list or export the entire fleet at once. Use GET only to verify the current state of a single vehicle in ROB-Net when needed.

Update a vehicle in the following order:

  1. First create or update the vehicle itself with PUT /v1/vehicles. The vehicle must exist before any of its related data can be updated.
  2. Next, update the related data — such as the current tire, last maintenance, contract tires, mileages, routings and purchased tires — through their dedicated sub-resource endpoints (see Vehicles below).
  3. When a vehicle is no longer relevant, remove it with DELETE /v1/vehicles/{licensePlate}.

Related data such as tires, mileage and maintenance is deliberately exposed as separate sub-resources rather than as part of the vehicle object. This lets you update only what has actually changed — for example a new mileage reading or a tire change — without resending the entire vehicle. It keeps each update small and unambiguous, and allows these independently changing parts to be updated on their own schedule.

Methods

This section describes the available methods of the ROB-Net REST API. More detailed information is available on the API Details page.

Vehicles

A vehicle is the central resource of this API and is uniquely identified by its licensePlate. Manage the vehicle itself through the /v1/vehicles endpoints:

  • PUT /v1/vehicles — creates a new vehicle, or updates it when the license plate already exists.
  • GET /v1/vehicles/{licensePlate} — retrieves the current details of a vehicle.
  • DELETE /v1/vehicles/{licensePlate} — removes the vehicle.

A vehicle has a number of related properties that are managed through their own sub-resources under /v1/vehicles/{licensePlate}. The vehicle must exist before these can be set:

  • contracttires — the tires covered by the vehicle's contract.
  • currenttire — the tires currently mounted on the vehicle.
  • lastmaintenance — the most recent maintenance data of the vehicle.
  • mileages — the registered mileage readings of the vehicle.
  • routings — the routing rules of the vehicle (mandatory and preferred routing to a supplier, dealer or SLA cluster).
  • extratireset — whether an extra tire set has been purchased.
  • purchasedtires — the purchase settings for the vehicle's tires (allowed and already purchased quantities per tire category and season).

Each sub-resource is updated with a PUT request and, where applicable, retrieved with GET or cleared with DELETE. The exact request and response models for every endpoint are documented on the API Details page.

Some of this data is also maintained by ROB-Net itself, so the value you last sent is not necessarily the current one. For that reason these sub-resources expose a GET endpoint — for example /v1/vehicles/{licensePlate}/currenttire — that lets you retrieve the latest state held in ROB-Net when you cannot determine it from your own system.