Meter property variables | Solvimon

A meter property variable is a named, reusable list of values bound to one meter property. A pricing condition matches against the list with IN or NOT_IN instead of repeating the values inline.

Why this matters

A condition that has to match a long set of values, for example every country in a region or every SKU in a product family, carries that set inside itself. Each pricing item config that needs the same set carries its own copy. When the set changes, you edit every copy, and nothing tells you when one copy drifts from the others.

A variable holds the set once. Conditions reference it, so the set has one definition, one place to change it, and one answer to “which plans use this list”. A variable holds up to 10,000 values, which is well past what is workable inline.

How it works

A variable belongs to exactly one meter property, set when you create it and fixed afterwards. Its values are strings, compared against the value the event carries for that property.

The values live on their own, not inside the variable. Reading a variable gives you a value_count rather than the list, so a listing stays readable when a variable holds thousands of values. You page through the values with their own endpoint.

Implementation

Create a variable

Create it with POST /v1/meter-property-variables. Name the property with meter_property_id or meter_property_reference, and pass the starting list in values:

Create a variable

curl -X POST https://test.api.solvimon.com/v1/meter-property-variables \
  -H "X-API-KEY: <apiKey>" \
  -H "Content-Type: application/json" \
  -d '{
    "reference": "eu-countries",
    "name": "EU countries",
    "description": "Member states billed at the intra-EU rate",
    "meter_property_reference": "country",
    "values": ["NL", "DE", "FR", "BE", "LU"]
  }'

Field	Required	Description
`reference`	Yes	Your own unique reference for the variable.
`name`	Yes	Display name.
`description`	No	What the list is for.
`meter_property_id` or `meter_property_reference`	Yes	The property whose values this variable lists. Set on create only.
`values`	No	The starting values. Edit them afterwards through the values endpoint.
`status`	No	Follows the usual resource lifecycle.

Response 201

{
  "object_type": "METER_PROPERTY_VARIABLE",
  "id": "mpva_2PnBx7VdtRgLmE4WcQJ8K",
  "reference": "eu-countries",
  "name": "EU countries",
  "meter_property_id": "mprp_5RmXe2QbtKfYuA9DcNH3P",
  "type": "STRING",
  "status": "ACTIVE",
  "value_count": 5,
  "created_at": "2026-09-30T09:12:00Z"
}

The response carries value_count, not the values. Read the values with GET /v1/meter-property-variables/{id}/values, which is paged. Each value carries the added_at of when it entered the list, so you can see what was added recently.

Reference it from a condition

A meter property condition takes meter_property_variable_id in place of inline values, with a comparator of IN or NOT_IN:

A condition that matches the variable

{
  "id": "mprp_5RmXe2QbtKfYuA9DcNH3P",
  "comparator": "IN",
  "meter_property_variable_id": "mpva_2PnBx7VdtRgLmE4WcQJ8K"
}

The condition sits where meter property conditions always sit, on the pricing item config of a usage-based product item. See Filtering on a meter property. Reading a condition back, you can expand meter_property_variable_id into meter_property_variable to get the variable inline:

Expand the variable on a condition

curl "https://test.api.solvimon.com/v1/pricing-plans/{id}?expand[]=meter_property_variable_id" \
  -H "X-API-KEY: <apiKey>"

Change the values

Values are edited through PATCH /v1/meter-property-variables/{id}/values, which takes an add set and a remove set and applies both as one change:

Add two values and remove one

curl -X PATCH https://test.api.solvimon.com/v1/meter-property-variables/eu-countries/values \
  -H "X-API-KEY: <apiKey>" \
  -H "Content-Type: application/json" \
  -d '{
    "add": ["IT", "ES"],
    "remove": ["LU"]
  }'

Response

{
  "added": ["IT", "ES"],
  "removed": ["LU"],
  "skipped": []
}

The response reports the outcome per value. A value you already hold is skipped rather than duplicated, and a value you do not hold is skipped on removal. Sending the same request twice therefore leaves the same list, which matters when a sync job replays a change.

Changing the list changes what future events match. Events that were already priced are not reprocessed. If you need a change applied to usage that is already billed, see Event reprocessing.

Via Desk

Meter property variables will have their own screen, where you create a variable against a property, see its values with the date each was added, and stage additions and removals before saving them as one change. The pricing condition editor offers the variables bound to the property you are filtering on. This part will be available soon.

Edge cases

A variable belongs to one property. meter_property_id is set on create and cannot be moved afterwards. A list that applies to two properties is two variables.
Deleting is blocked while it is in use. DELETE /v1/meter-property-variables/{id} only removes a variable that no condition references. Remove the conditions first.
The values are strings. They are compared against the event’s value for that property, under the same type validation as an inline condition value. See Filtering on a meter property.
IN and NOT_IN only. A variable is a set, so the comparators that take a set are the ones that accept it. A single-value comparator keeps using value.
10,000 values per variable. A list longer than that is usually a meter property in its own right, or a condition on something else about the event.