> ## Documentation Index
> Fetch the complete documentation index at: https://developers.lucca.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# The user resource

<Warning>
  This legacy resource has its equivalent in the **Lucca API**.

  The legacy user is a monolithic resource that only reflects the **current state** of an employee. The Lucca API introduces a richer model that tracks the **full career history** through dedicated, time-bound resources:

  * [Employee](/api-reference/latest/employees/employee) — core identity and organizational data.
  * [Employee personal record](/api-reference/latest/employees/employee-personal-record) — personal and private information.
  * [Employment](/api-reference/latest/employments/employment) — contractual relationship with a legal entity over time (replaces work-contracts).
  * [Job position](/api-reference/latest/employments/job-position) — department, manager, job title, and other career data, historized over the employee's tenure.

  The [employee-attributes API](/api-reference/latest/get-employee-attributes) also lets you retrieve all data for one or more employees in a single call — core fields, extensions, and application data — similar to what the legacy `?fields=` mechanism offers.

  Refer to the [getting started guide](/api-reference/latest/employees/get-started) for a complete overview, or the dedicated [migration guide](/api-reference/legacy/directory/guides/users-migration).
</Warning>

The v3 User is the representation of an employee in the Legacy API.

A v3 user is comprised of:

* a hard-coded set of attributes (e.g `firstName`, `mail`, `managerId`, etc...) called `coreData`;
* a dynamic set of extensions depending on installed applications called `applicationData`. Some of them are nested in a `applicationData` JSON object in read (GET) requests, and some are root properties.
* a dynamic set of custom extensions depending on the Employee Directory configuration called `extendedData`. Their names are prefixed with `"e_"`. For read requests, these are always nested in the `extendedData` attribute.

Examples:

| Name                | Description                                                  | Type              |
| :------------------ | :----------------------------------------------------------- | :---------------- |
| `address`           | Employee's personal address.                                 | `CodeData`        |
| `e_bloodType`       | Employee's blood  type.                                      | `ExtendedData`    |
| `profile_cleemy_89` | Employee's expenses management profile (for application 89). | `ApplicationData` |

<CodeGroup>
  ```json JSON theme={null}
  // Read
  {
      "data": {
          "id": 2938,
          // Dictionary of CoreData

          // Root level application data
          "frenchMotocyclesTaxHorsePower": "",
          "applicationData": {
              "profile_cleemy_89": {
                  "id": 12,
                  "name": "Regular employee",
                  "url": "https://example.ilucca.net/api/v3/expenseprofiles-89/12"
              }
              // Dictionary of ApplicationData
          },
          "extendedData": {
              "e_bloodType": "AB"
              // Dictionary of ExtendedData
          }
      }
  }
  ```
</CodeGroup>

The v3 user existed before the introduction of work-contracts, as a result, contractual information (establishment/legal-entity, contract start and end dates, etc...) now comes from the ["applicable" work-contract](./work-contract).

<Tip>You may not be able to retrieve all properties, as you may not have access to every single one of them.</Tip>

### About Extended Data(s)

[Read more about extended-data](./guides/extended-data)

### About User Axis Values

User axis values can be used for matching users and axis-sections. Common use-case is giving each user a cost center, which are `axis-sections` in a "Cost Center" `axis`. [Read more about axes and axis-sections](../organization/axis-sections/get-started).

In order to attach an axis-section of a given axis to a user, you may use dynamic properties whose key must match:
`{ "userAxisValues_{{axisId}}": {"id": {{axisSectionId}} }`.

For example, if user with ID 416 belongs to the cost center which corresponds to the axis-section with ID 35 in the axis with ID 2:

```json theme={null}
{
    "id": 416,
    ...
    "userAxisValues_2": {
    "id": 35
    }
}
```

### About Application Data

Application-data are custom extensions to the user/employees defined by installed applications on your Lucca account.

**About Lucca Expenses Profile**
Expenses management profile in Lucca Expenses.

Assigning a Lucca Expenses profile to a user is handled through a property whose name is dynamic, as it must conform to the pattern `"profile_cleemy_{{appInstanceId}}` where `appInstanceId` is the ID of the corresponding Cleemy Expense appplication instance (there can be more than one Cleemy Expenses application installed on any given account).

```json theme={null}
{
    "profile_cleemy_12": {
    "id": 34,
    "name": "Generic profile",
    "url": "..."
    }
}
```