Skip to content
flinkeyflinkey for Developers

Create user

PUT
/users
curl --request PUT \
  --url https://api-uat.flinkey.de/v3/users \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --header 'Customer-ID: example' \
  --header 'flinkey-API-Key: <flinkey-API-Key>' \
  --data '{ "type": "Anonymous" }'

Purpose

Create a new user 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 should usually create or resolve an anonymous flinkey user.

Anonymous users are used as technical access identities for partner app based integrations.

Anonymous users cannot sign in to the flinkey App for Android or iOS.

When to use this operation

Use this operation when the partner backend needs to create a new flinkey user for vehicle access.

Typical situations:

  • initial customer or driver setup,
  • creating an anonymous user for a partner app based integration,
  • preparing a user before assignment creation,
  • mapping a partner customer or driver to a flinkey user,
  • onboarding a new access identity for future vehicle assignments.

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

Do not create a new anonymous user for every booking unless that is the intended operating model.

Before creating a user, check whether a local user mapping already exists.

Validation notes

PROD validation result:

  • PUT /users with { "type": "Anonymous" } returned 201 Created.
  • The anonymous-user response contained a numeric id and password: null.
  • A subsequent user lookup returned an internally generated technical e-mail address, firstName: "unknown" and lastName: null.
  • Partner-provided e-mail and profile fields were accepted but ignored when type was Anonymous.
  • PUT /users with type: "Normal", e-mail address and profile data returned 201 Created.
  • The normal-user response contained a numeric id and a generated password string.
  • A subsequent user lookup returned the supplied e-mail address, first name and last name.
  • Repeating normal-user creation with the same e-mail address returned 409 Conflict with the message An user with the given e-mail address already exists.
  • All public examples use placeholders; generated passwords and real user data must not be documented.

Async behavior

Synchronous.

The API returns the created user ID and a password value. Use GET /users/{userId} to retrieve the persisted user profile.

Webhook result

No.

This operation does not produce a webhook result.

Security notes

Never log:

  • flinkey-API-Key,
  • bearer token,
  • full request headers,
  • returned password values.

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

Section titled “Authorizations”

Parameters

Section titled “Parameters”

Header Parameters

Section titled “Header Parameters”
Customer-ID
required
string

Customer database ID

Request Bodyrequired

Section titled “Request Bodyrequired”
Media typeapplication/json
object
emailAddress

Provide for a normal user. It is not required for the validated anonymous-user request.

string
userData

Provide for a normal user. It is not required for the validated anonymous-user request.

object
userData.firstName

First name for a normal user

string
userData.lastName

Last name for a normal user

string
password

Optional password input; not used in the validated requests

string | null
type

Use Anonymous or Normal

string
Example
{
  "type": "Anonymous"
}

Responses

Section titled “Responses”

201

Section titled “201”

User was created successfully

Media typeapplication/json
object
id

User database ID

number
password

Generated initial password for a normal user; null for an anonymous user in the validated responses

string | null
Example
{
  "id": 54321,
  "password": null
}

400

Section titled “400”

Request body is invalid

Recommended handling: Validate the request body for the selected user type

401

Section titled “401”

Invalid subscription key or missing / invalid access token

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

404

Section titled “404”

API Manager or customer context was not found

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

409

Section titled “409”

A normal user with the given e-mail address already exists

Recommended handling: Resolve and reuse the existing user instead of creating a duplicate

415

Section titled “415”

Request content type is missing or incorrect

Recommended handling: Ensure Content-Type: application/json is used

500

Section titled “500”

Server-side error

Recommended handling: Retry later if appropriate and escalate if persistent