> 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. # Event cost prediction > **Info** > > Please contact our commercial team if you are interested in using this functionality. The predicted cost of an ingested event can be obtained through two primary methods: **Solvimon Desk** and developers by incorporating a designated query parameter in the **API Request** during event ingestion. --- # API Request We will show the cost prediction in both Solvimon Desk and within the API Request for the following meter-data ingest event: **`JSON`** ```Text JSON { "meter_reference": "card_issuing", "customer_reference": "Customer_GUID", "reference": "event-ingestion-17-04-2023", "meter_values": [ { "reference": "card_count", "number": "1" } ], "meter_properties": [ { "reference": "card_type", "value": "Visa" }, { "reference": "card_use_frequency", "value": "Single" } ] } ``` The cost prediction will calculate the contribution of an ingested event for the provided customer (`customer_id`/`customer_reference`) and meter(`meter_id`/`meter_reference`). The predicted cost of the event is an estimation of the eventual price. Due to our multi-distributed platform events can be processed in parallel to support high throughput. As a result we can not guarantee 100% accuracy. An unlikely example is two events reaching our platform simultaneously. Both of which would result in the next tier being reached. # Event processing details In the Desk Events page, users have the ability to access detailed event information by selecting a specific event. When accessing, users are directed to the event processing details page, where a summary of the ingested event is shown, alongside the **cost estimation data**. ![](/_fern-img/a47a0a6dbe40e19836c54ecfb60fa30d366fe90a57d07c340bf0efb8cb8e6d06.webp) \ --- # API Response The [API docs](/platform-guides/for-developers/api) outline the specific query parameters available for each resource. To include predicted cost data in the response, developers should use the `cost_prediction` query parameter, setting it to a boolean value `true` when submitting a meter-data event ingestion request. When making a POST request to the endpoint `/v1/ingest/meter-data?cost_prediction=true` with the provided JSON payload, the response will contain an additional element called `cost_prediction`, structured as follows: **`JSON`** ```Text JSON { ... "cost_prediction": { "response": "OK", "details": [ { "customer_id": "cust_ywDeeN0teYVm9GAGeN1j", "amount_excluding_tax": { "quantity": "0.07", "currency": "EUR" }, "amount_including_tax": { "quantity": "0.08", "currency": "EUR" }, "tax_summary": { "base_amount": { "quantity": "0.07", "currency": "EUR" }, "tax_amount": { "quantity": "0.01", "currency": "EUR" }, "total_amount": { "quantity": "0.08", "currency": "EUR" }, "country_code": "NL" }, "periods": [ { ... } ] } ] } } ``` This JSON structure includes the following prediction details: 1. `response`: indicating either `OK` or `FAILED`. 2. `details` \[OPTIONAL]: an array containing cost predictions per customer, including the amount excluding and including tax, a tax summary, and the applicable periods. For more information on the `periods` structure, refer to the [API docs](/platform-guides/for-developers/api). The details object will be absent in the following scenarios: 1. The event resulted in no match for the combination customer, meter and subscription. Example given, when the event was ingested with a timestamp that was either before or after the subscription was active 2. The pricing configuration for which the event was matched against, has been configured with `pricing_type`: `NONE` also known as `Not billed`. The cost prediction will result in a 0 (zero) quantity when: 1. The pricing configuration has included volume and the event count is still within this included volume > **Warning** > > The `cost_prediction_groups` response field is deprecated, and will be replaced by the new `cost_prediction` structure. ## Wallet balance in the same response When the event is paid from a wallet, each entry in `details` also carries the wallet balance **before** and **after** the event: `pre_wallet_balance` and `post_wallet_balance`. Your application gets the event's cost and the resulting balance from the same synchronous ingest call, so it can show a running balance or stop a user who runs out of credits without a separate balance request. **`JSON`** ```Text JSON { ... "cost_prediction": { "response": "OK", "details": [ { "customer_id": "cust_ywDeeN0teYVm9GAGeN1j", ... "pre_wallet_balance": { "wallet_id": "wal_example", "wallet_balance": { "balance": { "credits": { "quantity": "2500", "credit_type_id": "ctyp_example" } }, "reserved_balance": { "credits": { "quantity": "20", "credit_type_id": "ctyp_example" } }, "open_balance": { "credits": { "quantity": "2480", "credit_type_id": "ctyp_example" } }, "balance_at": "2026-11-01T00:00:00Z" } }, "post_wallet_balance": { "wallet_id": "wal_example", "wallet_balance": { "balance": { "credits": { "quantity": "2500", "credit_type_id": "ctyp_example" } }, "reserved_balance": { "credits": { "quantity": "30", "credit_type_id": "ctyp_example" } }, "open_balance": { "credits": { "quantity": "2470", "credit_type_id": "ctyp_example" } }, "balance_at": "2026-11-01T00:00:00Z" } } } ] } } ``` In this example the event costs 10 credits: the reserved balance moves from 20 to 30 and the open balance from 2,480 to 2,470. `balance` does not change, because the credits are reserved until the invoice is finalized. Both objects have the same shape. The fields to read: | Field | Meaning | | --------------------------------- | -------------------------------------------------------------------------------------------------------- | | `wallet_id` | The credit wallet the event draws from: the customer's wallet for the credit type the usage is priced in | | `wallet_balance.balance` | Credits currently held in the wallet | | `wallet_balance.reserved_balance` | Credits committed to usage that has been metered but not yet invoiced | | `wallet_balance.open_balance` | `balance` minus `reserved_balance`: what the customer can still spend | | `wallet_balance.balance_at` | The end of the billing period the event falls in, which is the moment the balance is determined for | See [Reading a balance](/platform-guides/wallets-credits/credit-consumption-and-expiry#reading-a-balance) for how these figures relate. The wallet fields are absent when the usage is not paid from a credit wallet, or when no `details` are returned (see the scenarios above). A customer with several credit wallets gets the wallet for the credit type the event is priced in. Like the cost itself, the balances are a prediction made at ingest time: events processed in parallel for the same wallet can make the final balance differ slightly from the `post_wallet_balance` of an individual event. Read the authoritative balance with [`POST /v1/wallets/{id}/balance`](https://docs.solvimon.com/api-docs/configuration-api/wallets/post-wallets-by-resource-id-or-reference-balance): **`Read the current wallet balance`** ```bash Read the current wallet balance curl -X POST https://test.api.solvimon.com/v1/wallets/wal_example/balance \ -H "X-API-KEY: " \ -H "Content-Type: application/json" ``` ## Failed response Although the cost prediction is unlikely to fail, it is possible. If the `response` status is marked as `FAILED`, it indicates that either we were unable to calculate the cost for the event, or the calculation exceeded the allowed time limit of 5 seconds. This time constraint is imposed to prioritize the ingestion of the event over the completion of the cost prediction. There are two options to recover from this scenario: 1. Resubmit the event with the same reference. Due to [Idempotency](/platform-guides/for-developers/idempotency), the event details will not be processed again, so the invoice will **not** be affected. However, the cost prediction may differ slightly (e.g., if the initial estimate was 10 EUR, the new submission might result in 9 EUR due to tiered pricing). 2. Delete the initial event ingestion and then resubmit the event. > The second option requires a manual intervention to reprocess the invoice, before re-submitting the event ---