Add person limitations

This endpoint allows to create employee limitations for performing specific tasks.

POST /api/v1/business/{businessId}/employees/{employeeId}/locationLimitations

The URL must contain the business identifier (businessId) and the employee identifier (employeeId).

Below is an explanation of each field in the request body.

Mandatory fields are marked with an asterisk (*).

Request body

JSON Analysis 
{
  "lag": 0,
  "locationLimitations": [
    {
      "id": "string",
      "locationId": "string",
      "product": "string",
      "from": "string",
      "to": "string",
      "zone": "string",
      "location": "string"
    }
  ]
}
Details

  • lag*: number of days prior to the current date. Unlike other endpoints (see lag), here it also acts as a validation: no limitation sent can have a from date earlier than the current date minus this value.

  • locationLimitations*: list of limitations to be defined for the employee. Each one must contain the following data:

    • id: internal identifier of the limitation. It is not necessary to define it, the system will generate it automatically.

    • locationId: internal identifier of the task. It is not necessary to provide it.

    • product*: external identifier of the product or section.

    • from*: start date of the limitation period in yyyy-MM-dd format.

    • to: end date of the limitation period in yyyy-MM-dd format. It is possible to send null if the end date is unknown.

    • zone: external identifier of the zone. If no zone is specified, the limitation will be set for the task in the general zone.

    • location*: external identifier of the task for which the limitation is set.

Request example

After analyzing the different fields, here is an example request:

POST /api/v1/business/BUSINESSID/employees/EMPLOYEEID/locationLimitations
{
  "lag": 0,
  "locationLimitations": [
    {
      "product": "0001-GENERAL",
      "from": "2025-09-30",
      "to": null,
      "zone": "Z1",
      "location": "01"
    },
    {
      "product": "0001-GENERAL",
      "from": "2025-10-15",
      "to": "2025-10-25",
      "zone": "Z1",
      "location": "02"
    }
  ]
}

If the request data is correct, the request will return a 200 OK status and the limitations will be set for the employee in the specified tasks.

Considerations

A lag equal to 0 deletes the employee’s entire limitation history, not only the limitations of the request period: internally it is interpreted as "no start date" for the prior deletion, so it is strongly recommended to always send a positive value unless the intention is to completely clear the employee’s existing limitations.

Unlike other endpoints that integrate lists of elements (see lag), here lag is not limited to protecting existing information from deletion: it also validates the limitations sent in the request itself. If any of them has a from date earlier than the current date minus lag days, the entire request is rejected with the not_in_range error.

To visualize the limitations in the interface, the employee must already have the aptitude defined for that task.

Error codes

In addition to the common errors, this endpoint can return the following codes:

Code Message Description

400 Bad Request

-

The request body is not valid JSON or one of its fields does not have the expected format.

406 Not Acceptable

Lag mut be positive or zero

The lag field is negative. It is recommended to send a value of 0 or a positive one. (The exact literal reproduces a typo in the backend itself: "mut" instead of "must".)

Limitations list cannot be null

The locationLimitations field cannot be missing or empty.

invalid_to_date

The to date of a limitation is earlier than its from date.

-

not_in_range

The from date of a limitation sent in the request is earlier than the current date minus lag days.

Useful links

What is a task? And what is an aptitude in a task?

What is lag in a request?