Get users

GET

/users

const url = 'https://api-uat.flinkey.de/v3/users';
const options = {
  method: 'GET',
  headers: {
    'Customer-ID': 'example',
    'flinkey-API-Key': '<flinkey-API-Key>',
    Authorization: 'Bearer <token>'
  }
};

try {
  const response = await fetch(url, options);
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.error(error);
}

curl --request GET \
  --url https://api-uat.flinkey.de/v3/users \
  --header 'Authorization: Bearer <token>' \
  --header 'Customer-ID: example' \
  --header 'flinkey-API-Key: <flinkey-API-Key>'

Purpose

Retrieve users available in the selected customer context.

A user represents the access identity that can receive assignments for cars.

For standard full partner integrations, the partner backend usually works with anonymous flinkey users.

The returned user IDs can be used to inspect, reconcile or assign access to users.

When to use this operation

Use this operation when the partner backend needs to retrieve or search existing users.

Typical situations:

initial integration setup,
checking whether a user already exists before creating a new one,
validating the local mapping between partner customers or drivers and flinkey users,
troubleshooting assignment creation,
reconciling partner customer or driver records with flinkey user records.

In most integrations, the partner backend should persist a mapping between the partner customer or driver and the flinkey userId.

Do not create duplicate anonymous users without checking existing mappings first.

Validation notes

PROD validation result:

GET /users was successfully executed with flinkey-API-Key, Authorization: Bearer {{accessToken}} and Customer-ID.
The response was an array of user objects.
id was returned as a number.
emailAddress was returned as a string in the validated response set.
userData was returned as an object containing firstName and lastName in the validated response set.
$top, $skip, $orderby and $filter were successfully validated.
$filter was validated with the top-level field id and with the nested OData path userData/firstName.
$select is not supported by the flinkey API and must not be used.
No default response ordering is guaranteed; use $orderby when deterministic ordering is required.
Production names and email addresses used during validation were not copied into this documentation.

Async behavior

Synchronous.

The users are returned directly in the API response.

Webhook result

No.

This operation does not produce a webhook result.

Security notes

Never log:

flinkey-API-Key,
bearer token,
full request headers.

User identifiers are environment-specific.

Do not mix UAT and PROD user IDs.

Use placeholders in documentation, examples, screenshots and AI prompts.

For standard partner integrations, the mobile app must not receive API Manager credentials, backend bearer tokens or the flinkey-API-Key.

Authorizations

apiKey
bearerAuth

Parameters

Header Parameters

Customer-ID

required

string

Customer database ID

Responses

200

Users were retrieved successfully

application/json

Array<object>

object

User database ID

number

emailAddress

E-mail address of the user

string

userData

User profile data

object

userData.firstName

First name

string | null

userData.lastName

Last name

string | null

Example

[
  {
    "id": 54321,
    "emailAddress": "user@example.com",
    "userData": {
      "firstName": "Max",
      "lastName": "Mustermann"
    }
  }
]

401

Invalid subscription key or missing / invalid access token

Recommended handling: Check flinkey-API-Key, bearer token and environment configuration

404

API Manager or customer context was not found

Recommended handling: Check credentials, token context and Customer-ID

500

Server-side error

Recommended handling: Retry later if appropriate and escalate if persistent