Get assignments of user

GET

/users/{userId}/assignments

const url = 'https://api-uat.flinkey.de/v3/users/1/assignments';
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/1/assignments \
  --header 'Authorization: Bearer <token>' \
  --header 'Customer-ID: example' \
  --header 'flinkey-API-Key: <flinkey-API-Key>'

Purpose

Retrieve assignments for one specific user in the selected customer context.

An assignment grants access from a user to a car for a defined time range.

Use this operation to inspect which assignments exist for a specific user.

The returned assignment data can be used for reconciliation, support workflows or backend state validation.

When to use this operation

Use this operation when the partner backend needs to retrieve assignments related to one specific flinkey user.

Typical situations:

checking which cars a user currently has access to,
validating assignment state for a user,
troubleshooting mobile access for a specific user,
troubleshooting assignment creation,
reconciling partner customer or driver access records with flinkey assignment records,
inspecting assignment start and end times for a user.

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

Use the mapped userId to retrieve assignments for the correct flinkey user.

Do not create new assignments before checking whether the intended access already exists, if duplicate access would cause operational issues.

Validation notes

PROD validation result:

GET /users/{userId}/assignments was successfully executed with flinkey-API-Key, Authorization: Bearer {{accessToken}} and Customer-ID.
The response is an array.
id is returned as number.
carId is returned as number.
start is returned as UTC timestamp string.
end may be null.
lifetime is returned as number when provided.
renewableAfter may be a number or null.
The response model does not include userId; the user context is defined by the path parameter.
$top, $skip, $filter and $orderby are supported.
$select is not supported by the flinkey API and must not be used.
No default response order should be assumed; use $orderby when order matters.

Async behavior

Synchronous.

The assignments 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 and assignment identifiers are environment-specific.

Do not mix UAT and PROD user IDs or assignment 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

Path Parameters

userId

required

number

Database ID of the user

Header Parameters

Customer-ID

required

string

Customer database ID

Responses

200

Assignments of the user were retrieved successfully

application/json

Array<object>

object

Assignment database ID

number

carId

Car database ID assigned to the user

number

start

Assignment start time as UTC timestamp

string

end

Assignment end time as UTC timestamp, or null for open-ended access

string | null

lifetime

Assignment lifetime in seconds, if provided

number | null

renewableAfter

Renewal-related value returned by the API, if applicable

number | null

Example

[
  {
    "id": 10001,
    "carId": 20001,
    "start": "2026-01-31T10:00:00.000Z",
    "end": null,
    "lifetime": 604800,
    "renewableAfter": null
  },
  {
    "id": 10002,
    "carId": 20002,
    "start": "2026-02-01T08:00:00.000Z",
    "end": "2026-02-01T18:00:00.000Z",
    "lifetime": 604800,
    "renewableAfter": null
  }
]

401

Invalid subscription key or missing / invalid access token

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

404

API Manager, customer context or user assignment data was not found

Recommended handling: Check credentials, Customer-ID and local userId mapping

500

Server-side error

Recommended handling: Retry later if appropriate and escalate if persistent