> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.solvimon.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.solvimon.com/_mcp/server. # Meter property variables A meter property variable is a named, reusable list of values bound to one [meter property](/platform-guides/meter-and-event-design/meter/meter-properties). 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. ```mermaid erDiagram METER ||--o{ METER-PROPERTY : defines METER-PROPERTY ||--o{ METER-PROPERTY-VARIABLE : "is listed by" METER-PROPERTY-VARIABLE ||--o{ METER-PROPERTY-VARIABLE-VALUE : holds PRICING-ITEM-CONFIG ||--o{ METER-PROPERTY-CONDITION : filters-on METER-PROPERTY-CONDITION }o--|| METER-PROPERTY-VARIABLE : references ``` 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](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/post-meter-property-variables). Name the property with `meter_property_id` or `meter_property_reference`, and pass the starting list in `values`: **`Create a variable`** ```bash Create a variable curl -X POST https://test.api.solvimon.com/v1/meter-property-variables \ -H "X-API-KEY: " \ -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`** ```json 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](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/get-meter-property-variables-by-resource-id-or-reference-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`** ```json 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](/platform-guides/meter-and-event-design/meter/meter-properties#filtering-on-a-meter-property). Reading a condition back, you can [expand](/platform-guides/for-developers/expanding-responses) `meter_property_variable_id` into `meter_property_variable` to get the variable inline: **`Expand the variable on a condition`** ```bash 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: " ``` ### Change the values Values are edited through [PATCH /v1/meter-property-variables/\{id}/values](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/patch-meter-property-variables-by-resource-id-or-reference-values), which takes an `add` set and a `remove` set and applies both as one change: **`Add two values and remove one`** ```bash 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: " \ -H "Content-Type: application/json" \ -d '{ "add": ["IT", "ES"], "remove": ["LU"] }' ``` **`Response`** ```json 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. > **Note** > > 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](/platform-guides/meter-and-event-design/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}](https://docs.solvimon.com/api-docs/configuration-api/meter-property-variables/delete-meter-property-variables-by-resource-id-or-reference) 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](/platform-guides/meter-and-event-design/meter/meter-properties#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. --- See also: [Meter properties](/platform-guides/meter-and-event-design/meter/meter-properties), [Meters](/platform-guides/meter-and-event-design/meter) and [Designing your meters & events](/platform-guides/meter-and-event-design/designing-meters-and-events).