# Update a subscription order item

Updates a subscription order item. This is an experimental endpoint, can be changed or removed in the future.

Endpoint: PATCH /subscriptions/{id}/items/{itemId}
Version: latest
Security: SecretApiKey, JWT

## Path parameters:

  - `id` (string, required)
    ID of the resource.

  - `itemId` (string, required)
    ID of subscription item.

## Request fields (application/json):

  - `quantityFilled` (number, required)
    Filled quantity of the subscription item (experimental property).
    Example: 5.125

  - `excludeFromMrr` (boolean)
    Specifies if this item should be excluded from monthly recurring revenue calculations.

## Response 200 fields (application/json):

  - `id` (string)
    ID of the order item.

  - `quantity` (integer)
    Number of product units in the specified plan.

  - `quantityFilled` (number)
    Number of filled product units.
    Example: 5.125

  - `plan` (any, required)

  - `usageLimits` (object,null)
    Specifies the soft and hard usage limit thresholds for an item with a metered billing plan.
This value is ignored when the plan is not metered.

  - `usageLimits.softLimit` (object)
    Defines thresholds for notification purposes.
For example, to notify the customer that their usage is near the hard limit of their metered billing plan.
This notification informs the customer so that they can upgrade their plan before the hard limit is reached.
When the reported usage reaches 75%, 90%, and 100% of the configured limit a specific event is triggered.
To notify the customer, a webhook and notification can be configured for this event.
This field is useful for accounting and customer success purposes.
The usage of metered billing plans can still be reported if the soft limit is reached.

  - `usageLimits.softLimit.quantity` (integer)
    Usage limit quantity.

  - `usageLimits.softLimit.amount` (number)
    Usage limit amount in the currency of the order.

  - `usageLimits.hardLimit` (object)
    Defines a limit where the customer can no longer use the service.
Hard limits are used in addition to soft limits.
When a soft limit is reached,
a customer may receive a notification
but the service can still be provided up to the hard limit value so that the customer can upgrade their plan.
When the reported usage reaches the configured limit,
a specific event is triggered.
To notify the customer in the merchant system,
or block a service,
a webhook and notification can be configured for this event.
When the total usage reaches the hard limit quantity,
or amount values,
metered billing plan usages can no longer be reported.

  - `usageLimits.trialLimit` (object,null)
    Defines a usage cap during the trial period of a subscription.
This limit is enforced only while the subscription is in its trial phase.
When the reported usage reaches the configured trial limit, an event called 'trial-usage-limit-reached' is triggered.
To notify the customer or restrict access to the service, a webhook and notification can be configured for this event.
Once the trial limit is reached, additional usage cannot be reported unless the trial ends.
    Example: 20.725

  - `usageStatus` (object,null)
    Current status of the usage limits.

  - `usageStatus.isSoftLimitReached` (boolean)
    Specifies if the soft limit has been reached.

  - `usageStatus.isHardLimitReached` (boolean)
    Specifies if the hard limit has been reached.

  - `usageStatus.isTrialLimitReached` (boolean)
    Specifies if the trial limit has been reached.

  - `revision` (integer)
    Revision number that increments with each overriding change to this specific plan item.

  - `isModified` (boolean)
    Specifies if the plan information is modified for this subscription.

  - `isGrandfathered` (boolean)
    Specifies if the current plan revision number is greater than the plan item revision number.

  - `excludeFromMrr` (boolean)
    Specifies if this item should be excluded from monthly recurring revenue calculations.

  - `_embedded` (object)
    Embedded objects that are requested by the  query parameter.

  - `_embedded.product` (object)

  - `planId` (string)
    ID of the plan.
    Example: "plan_0YV7DENSVGDBW9S71XZNNYYQ0X"

## Response 401 fields (application/json):

  - `status` (integer)
    HTTP status code.

  - `type` (string)
    Problem type in the form of a [URI](https://tools.ietf.org/html/rfc3986) reference.
It should provide human-readable documentation for the problem type.
When this member is not present, its value is assumed to be "about:blank".

  - `title` (string)
    Short, human-readable summary of the problem type.
Other than for the purposes of localization, this should not change from occurrence to occurrence of the problem.

  - `detail` (string)
    Human-readable explanation that is specific to this occurrence of the problem.

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem.
It may or may not yield further information if dereferenced.

## Response 403 fields (application/json):

  - `status` (integer)
    HTTP status code.

  - `type` (string)
    Problem type in the form of a [URI](https://tools.ietf.org/html/rfc3986) reference.
It should provide human-readable documentation for the problem type.
When this member is not present, its value is assumed to be "about:blank".

  - `title` (string)
    Short, human-readable summary of the problem type.
Other than for the purposes of localization, this should not change from occurrence to occurrence of the problem.

  - `detail` (string)
    Human-readable explanation that is specific to this occurrence of the problem.

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem.
It may or may not yield further information if dereferenced.

## Response 422 fields (application/json):

  - `status` (integer)
    HTTP status code.

  - `type` (string)
    Problem type in the form of a [URI](https://tools.ietf.org/html/rfc3986) reference.
It should provide human-readable documentation for the problem type.
When this member is not present, its value is assumed to be "about:blank".

  - `title` (string)
    Short, human-readable summary of the problem type.
Other than for the purposes of localization, this should not change from occurrence to occurrence of the problem.

  - `detail` (string)
    Human-readable explanation that is specific to this occurrence of the problem.

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem.
It may or may not yield further information if dereferenced.

  - `invalidFields` (array)
    Invalid field details.
    Example: [{"field":"field1","message":"field1 is invalid"},{"field":"subObject.field2","message":"field2 is invalid"},{"field":"subObject.field2","message":"another error in the field2"}]

  - `invalidFields.field` (string)
    Name of the field.
Dot notation is used for nested object field names.

  - `invalidFields.message` (string)
    Message field.

## Response 429 fields (application/json):

  - `type` (string)
    Problem type in the form of a [URI](https://tools.ietf.org/html/rfc3986) reference.
It should provide human-readable documentation for the problem type.
When this member is not present, its value is assumed to be "about:blank".
    Example: "about:blank"

  - `title` (string)
    Short, human-readable summary of the problem type.
Other than for the purposes of localization, this should not change from occurrence to occurrence of the problem.
    Example: "Rate Limit Exceeded"

  - `status` (integer)
    HTTP status code.

  - `detail` (string)
    Human-readable explanation that is specific to this occurrence of the problem.
    Example: "A request cannot be executed because the user has sent too many requests within a certain period of time"

  - `instance` (string)
    URI reference that identifies the specific occurrence of the problem.
It may or may not yield further information if dereferenced.