# Upsert location workload levelling set

Create or update a `location workload levelling set`. A unique ID (`business_id`) is required to identify the `location workload levelling set`.
Calling this endpoint with an existing `business_id` will update the `location workload levelling set`.

Endpoint: PUT /settings/location-workload-levelling-sets/{business_id}
Version: v1.23.0
Security: clientCredentials

## Path parameters:

  - `business_id` (string, required)
    The unique identifier of an entity

## Header parameters:

  - `If-Match` (string)
    Weak Etag used for optimistic locking.

## Request fields (application/json):

  - `business_id` (string)
    Example: cb1fb12c-0abc-413c-a69d-63c62566685f

  - `name` (string)
    The name of the location workload levelling set
    Example: Weekday

  - `settings` (array)

  - `settings.location_business_ids` (array)
    List of business IDs of locations this setting applies to
    Example: ["LOC_001","LOC_002"]

  - `settings.loading_zones` (array)
    List of loading zones available at the locations

  - `settings.loading_zones.cost` (number)
    The cost associated with using this loading zone
    Example: 10

  - `settings.minimum_buffer_duration` (string)
    The minimum buffer duration between vehicles using the same loading zone. Must be an ISO-8601 compliant Duration string.
    Example: PT30M

## Response 400 fields (application/problem+json):

  - `type` (string, required)
    An absolute URI that identifies the problem type.  When dereferenced,
it SHOULD provide human-readable documentation for the problem type
(e.g., using HTML).
    Example: https://developer.conundra.eu/developer-portal/problem/#constraint-violation

  - `title` (string, required)
    A short, summary of the problem type. Written in english and readable
for engineers (usually not suited for non technical stakeholders and
not localized)
    Example: Bad Request

  - `status` (integer, required)
    The HTTP status code generated by the origin server for this occurrence
of the problem.
    Example: 400

  - `detail` (string, required)
    A human readable explanation specific to this occurrence of the
problem.
    Example: Bad request. See violations for more details.

  - `violations` (array)

  - `violations.field` (string)
    A reference to the field in the request that triggered this violation.
    Example: limit

  - `violations.message` (string, required)
    A message explaining the violation in the referenced field.
    Example: Limit must be strictly positive.

## Response 404 fields (application/problem+json):

  - `type` (string, required)
    An absolute URI that identifies the problem type.  When dereferenced,
it SHOULD provide human-readable documentation for the problem type
(e.g., using HTML).
    Example: https://developer.conundra.eu/developer-portal/problem/#constraint-violation

  - `title` (string, required)
    A short, summary of the problem type. Written in english and readable
for engineers (usually not suited for non technical stakeholders and
not localized)
    Example: Bad Request

  - `status` (integer, required)
    The HTTP status code generated by the origin server for this occurrence
of the problem.
    Example: 400

  - `detail` (string, required)
    A human readable explanation specific to this occurrence of the
problem.
    Example: Bad request. See violations for more details.

  - `violations` (array)

  - `violations.field` (string)
    A reference to the field in the request that triggered this violation.
    Example: limit

  - `violations.message` (string, required)
    A message explaining the violation in the referenced field.
    Example: Limit must be strictly positive.

## Response 409 fields (application/problem+json):

  - `type` (string, required)
    An absolute URI that identifies the problem type.  When dereferenced,
it SHOULD provide human-readable documentation for the problem type
(e.g., using HTML).
    Example: https://developer.conundra.eu/developer-portal/problem/#constraint-violation

  - `title` (string, required)
    A short, summary of the problem type. Written in english and readable
for engineers (usually not suited for non technical stakeholders and
not localized)
    Example: Bad Request

  - `status` (integer, required)
    The HTTP status code generated by the origin server for this occurrence
of the problem.
    Example: 400

  - `detail` (string, required)
    A human readable explanation specific to this occurrence of the
problem.
    Example: Bad request. See violations for more details.

  - `violations` (array)

  - `violations.field` (string)
    A reference to the field in the request that triggered this violation.
    Example: limit

  - `violations.message` (string, required)
    A message explaining the violation in the referenced field.
    Example: Limit must be strictly positive.

## Response 412 fields (application/problem+json):

  - `type` (string, required)
    An absolute URI that identifies the problem type.  When dereferenced,
it SHOULD provide human-readable documentation for the problem type
(e.g., using HTML).
    Example: https://developer.conundra.eu/developer-portal/problem/#constraint-violation

  - `title` (string, required)
    A short, summary of the problem type. Written in english and readable
for engineers (usually not suited for non technical stakeholders and
not localized)
    Example: Bad Request

  - `status` (integer, required)
    The HTTP status code generated by the origin server for this occurrence
of the problem.
    Example: 400

  - `detail` (string, required)
    A human readable explanation specific to this occurrence of the
problem.
    Example: Bad request. See violations for more details.

  - `violations` (array)

  - `violations.field` (string)
    A reference to the field in the request that triggered this violation.
    Example: limit

  - `violations.message` (string, required)
    A message explaining the violation in the referenced field.
    Example: Limit must be strictly positive.