> 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. # Webhook event types This page lists every event that Solvimon can send to a webhook. It shows the object types that you can subscribe to, their actions and sub-actions, and when each event fires. --- ## Why this matters A webhook only receives the events you subscribe to, and Solvimon matches event names exactly. Transition events such as `INVOICE.STATUS_TO_FINAL` or `QUOTE_VERSION.SIGNED` are separate events: subscribing to `INVOICE.UPDATED` does not include them. Use this page to pick the exact values for `included_actions` and `excluded_actions`. ## How it works An event name is the object type and the action, in uppercase, separated by a period: `OBJECT_TYPE.ACTION`. Solvimon sends the name as `type` in the [webhook payload](/platform-guides/for-developers/webhooks). Actions come in two kinds: | Kind | Values | Meaning | | ----------- | ---------------------------------------------- | --------------------------------------------------------------------------------------- | | Base action | `CREATED`, `UPDATED`, `DELETED` | The resource was created, changed or deleted. Not every object type supports all three. | | Sub-action | `STATUS_TO_FINAL`, `PAID`, `SIGNED` and others | A specific transition on the resource. Only some object types have them. | When a change triggers a sub-action, Solvimon sends the sub-action event. For most object types, it also sends the base `UPDATED` event as a separate delivery. In each delivery, `data` contains the resource after the change. When the webhook has `include_previous_data` enabled, `previous_data` contains the resource before the change. A webhook decides what it receives with two lists: | `included_actions` | `excluded_actions` | Your webhook receives | | ------------------ | ------------------ | ----------------------------------- | | Not set or empty | Not set or empty | Every event. | | Set | Ignored | Only the listed events. | | Not set | Set | Every event except the listed ones. | To receive every event except a few, leave `included_actions` out of the request and set only `excluded_actions`. There are no wildcards. To receive every invoice transition, list each `INVOICE.*` event that you need. The API rejects an unknown value when you create or update the webhook. ## List the available events [GET /v1/webhooks/actions](https://docs.solvimon.com/api-docs/configuration-api/webhooks/get-webhooks-actions) returns every object type and the actions you can use for it. It is the source of truth for your platform, so use it to validate your configuration. **`Get the available webhook actions`** ```bash Get the available webhook actions curl https://test.api.solvimon.com/v1/webhooks/actions \ -H "X-API-KEY: " ``` **`Response (shortened)`** ```json Response (shortened) { "data": [ { "object_type": "ALERT", "actions": ["CREATED"] }, { "object_type": "INVOICE", "actions": [ "CREATED", "UPDATED", "DELETED", "PAID", "STATUS_TO_FINAL", "STATUS_UPDATED", "STATUS_TO_VOID", "SEND_BY_EMAIL", "EXPORT_TO_ERP" ] }, { "object_type": "PAYMENT", "actions": ["CREATED", "UPDATED"] } ] } ``` ## Subscribe to events Pass the event names in `included_actions` when you create or update a webhook: **`Subscribe to invoice and payment events`** ```bash Subscribe to invoice and payment events curl -X POST https://test.api.solvimon.com/v1/webhooks \ -H "X-API-KEY: " \ -H "Content-Type: application/json" \ -d '{ "name": "Billing events", "reference": "billing-events", "url": "https://example.com/webhooks/solvimon", "included_actions": [ "INVOICE.STATUS_TO_FINAL", "INVOICE.PAID", "INVOICE.STATUS_TO_VOID", "PAYMENT.CREATED", "PAYMENT.UPDATED" ] }' ``` **`Response (shortened)`** ```json Response (shortened) { "object_type": "WEBHOOK", "id": "webh_NwDzWt0vKj4HpYFx6m1S", "name": "Billing events", "reference": "billing-events", "url": "https://example.com/webhooks/solvimon", "included_actions": [ "INVOICE.STATUS_TO_FINAL", "INVOICE.PAID", "INVOICE.STATUS_TO_VOID", "PAYMENT.CREATED", "PAYMENT.UPDATED" ], "active": true } ``` ## Sub-action events These are the only events that are not `CREATED`, `UPDATED` or `DELETED`. ### Invoice | Event | When it fires | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `INVOICE.STATUS_TO_FINAL` | The invoice status changes to `FINAL`. Use this to send receipts or sync the invoice to your system. | | `INVOICE.STATUS_TO_VOID` | The invoice status changes to `VOID`. | | `INVOICE.STATUS_UPDATED` | The invoice status changes to `FUTURE`, `OPEN`, `DRAFT`, `EMPTY` or `ARCHIVED`. Changes to `FINAL` and `VOID` have their own events and do not fire this one. | | `INVOICE.PAID` | The invoice's `paid` flag changes to `true`. This can fire together with `STATUS_TO_FINAL`. | | `INVOICE.SEND_BY_EMAIL` | The invoice is ready for your own system to email. Fires after finalization when all of these are true: the platform's `invoice_settings.send_by_email.trigger_type` is `AUTOMATIC`. The customer's notification preferences allow invoice emails. No active send-email [workflow](/platform-guides/workflows/workflow-actions) applies. Also fires every time someone sends a final invoice by email from Desk or with `POST /v1/invoices/{id}/send_by_email`. | | `INVOICE.EXPORT_TO_ERP` | The invoice is ready for export to your ERP. Fires after finalization when `invoice_settings.export_to_erp.trigger_type` is `AUTOMATIC`. Also fires from an `EXPORT_TO_ERP` workflow action with a third-party executor. Also fires when someone exports a final invoice from Desk or with `POST /v1/invoices/{id}/export_to_erp`. | For `SEND_BY_EMAIL` and `EXPORT_TO_ERP`, `data` holds the invoice and `previous_data` is `null`. An `EXPORT_TO_ERP` event that a workflow sends also contains `metadata` with `workflow_action_id`, `workflow_trigger_id` and `workflow_action_execution_id`. Your integration can use these IDs to report the result back to that workflow execution. > **Warning** > > `INVOICE.UPDATED` only fires when an invoice changes to `FINAL`, at the same moment as `INVOICE.STATUS_TO_FINAL`. Solvimon keeps it for existing integrations and will deprecate it. Subscribe to `INVOICE.STATUS_TO_FINAL` instead, and to the other sub-actions for the transitions you need. ### Pricing plan schedule | Event | When it fires | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | `PRICING_PLAN_SCHEDULE.STATUS_UPDATED` | A draft schedule is activated. | | `PRICING_PLAN_SCHEDULE.APPROVAL_STATUS_UPDATED` | The schedule's approval status changes, for example when an approver approves or declines a price change. | Both also send `PRICING_PLAN_SCHEDULE.UPDATED`. ### Quote version | Event | When it fires | | ----------------------------------- | ---------------------------------------------------------------------------------------------------- | | `QUOTE_VERSION.SIGNATURE_REQUESTED` | A signature request is created for the quote version. | | `QUOTE_VERSION.SIGNED` | The signature request is complete. Every recipient signed, or a user completed the request manually. | Both also send `QUOTE_VERSION.UPDATED`. `SIGNED` also sends `SIGNATURE_REQUEST.UPDATED` for the signature request itself. ### File | Event | When it fires | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `FILE.STATUS_UPDATED` | The status of a [file](/platform-guides/meter-and-event-design/usage-events/file-uploads) changes, whether it was uploaded through the API or to a bucket. Also sends `FILE.UPDATED`. | ### Meter data | Event | When it fires | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `METER_DATA.DUPLICATE` | An ingested event is a duplicate of an earlier event with the same reference, so it is not billed. | | `METER_DATA.NOT_MATCHED` | Solvimon did not match an ingested event to a subscription, schedule or price, so it does not bill the event. The reason is in `data.processed_details.not_matched.variant`. See [Unbilled usage](/platform-guides/meter-and-event-design/unmatched-events). | Replayed events do not send these. The API accepts `METER_DATA.CREATED` in `included_actions`, but Solvimon does not send it. ### Usage limit threshold Solvimon sends `USAGE_LIMIT.THRESHOLD_REACHED` when a [usage-limit workflow](/platform-guides/meter-and-event-design/usage-limits) with a `SEND_WEBHOOK` action crosses a threshold. Solvimon delivers it to the webhook that the action references, and ignores that webhook's `included_actions`. It is not a valid `included_actions` value. `data` holds `workflow_id`, `workflow_trigger_id`, `customer_id`, `parent_customer_id`, `meter_value_calculation_id`, `threshold`, `threshold_type`, `limit`, `consumed`, `period_start`, `period_end` and `triggered_at`. ## Example sub-action payload This example shows an `INVOICE.STATUS_TO_FINAL` delivery with `include_previous_data` enabled. `data` and `previous_data` contain the full invoice in the same shape as [GET /v1/invoices/\{id}](https://docs.solvimon.com/api-docs/transaction-api/invoices/get-invoices-by-resource-id). The example is shortened. **`INVOICE.STATUS_TO_FINAL`** ```json INVOICE.STATUS_TO_FINAL { "created_at": "2026-10-01T00:15:02Z", "type": "INVOICE.STATUS_TO_FINAL", "original_request_id": null, "environment": "TEST", "previous_data": { "object_type": "INVOICE", "id": "invo_PwDkYv0xMn6KrAHz8p1V", "status": "DRAFT", "paid": false }, "data": { "object_type": "INVOICE", "id": "invo_PwDkYv0xMn6KrAHz8p1V", "status": "FINAL", "paid": false } } ``` ## Object types and actions C = `CREATED`, U = `UPDATED`, D = `DELETED`. Sub-actions are listed in [Sub-action events](#sub-action-events). ### Invoicing and payments | Object type | Actions | Fires when | | ------------------ | --------------------- | ----------------------------------------------------------------------------- | | `INVOICE` | C, U, D + sub-actions | An invoice is created or deleted. `UPDATED` only on finalization, see above. | | `PAYMENT` | C, U | A payment attempt is made and when its result changes. There is no `DELETED`. | | `PAYMENT_METHOD` | C, U, D | A customer's stored payment method changes. | | `PAYMENT_ACCEPTOR` | C, U, D | A payment acceptor changes. | | `BILLING_ENTITY` | C, U, D | A billing entity changes. | ### Customers and subscriptions | Object type | Actions | Fires when | | --------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `CUSTOMER` | C, U, D | A customer changes. | | `CONTACT` | C, U, D | A contact changes. | | `PRICING_PLAN_SUBSCRIPTION` | C, U, D | A subscription changes, including activation, cancellation, upgrade and voiding. These do not have their own events: compare `status` in `data` and `previous_data`. | | `PRICING_PLAN_SUBSCRIPTION_GROUP` | C, U, D | A subscription group changes. | | `PRICING_PLAN_SCHEDULE` | C, U, D + sub-actions | A schedule changes. | | `SEAT_ASSIGNMENT` | C, U, D | A seat is assigned, changed or removed. | | `USAGE_LIMIT` | C, U, D | A usage limit changes. | ### Quotes and approvals | Object type | Actions | Fires when | | ------------------- | --------------------- | --------------------------------------------------------------------------------------------- | | `QUOTE` | C, U, D | A quote changes. | | `QUOTE_VERSION` | C, U, D + sub-actions | A quote version changes. | | `QUOTE_TEMPLATE` | C, U, D | A quote template changes. | | `SIGNATURE_REQUEST` | C, U | A signature request is created, and when a recipient acts on it or it is completed or voided. | | `APPROVAL_POLICY` | C, U, D | An approval policy changes. | | `APPROVAL_REQUEST` | C, U, D | An approval request is created or decided. | | `ATTACHMENT` | C, D | An attachment is added or removed. | | `DOCUMENT` | C, D | A document is stored or removed. | ### Products and pricing | Object type | Actions | Fires when | | ---------------------- | ------- | ---------------------------------- | | `PRODUCT` | C, U, D | A product changes. | | `PRODUCT_ITEM` | C, U, D | A product item changes. | | `PRODUCT_CATEGORY` | C, U, D | A product category changes. | | `FEATURE` | C, U, D | A feature changes. | | `PRICING_PLAN` | C, U, D | A pricing plan changes. | | `PRICING_PLAN_VERSION` | C, U, D | A pricing plan version changes. | | `PRICING_PLAN_GROUP` | C, U, D | A pricing plan group changes. | | `COUPON` | C, U, D | A coupon changes. | | `PROMOTION_CODE` | C, U, D | A promotion code changes. | | `CUSTOM_FIELD` | C, U, D | A custom field definition changes. | ### Usage metering | Object type | Actions | Fires when | | -------------------------- | -------------------- | --------------------------------------------------- | | `METER` | C, U, D | A meter changes. | | `METER_PROPERTY` | C, U, D | A meter property changes. | | `METER_PROPERTY_VARIABLE` | C, U, D | A meter property variable changes. | | `METER_VALUE` | C, U, D | A meter value changes. | | `METER_VALUE_CALCULATION` | C, U, D | A meter value calculation changes. | | `METER_DATA` | sub-actions only | An ingested event is a duplicate or is not matched. | | `FILE` | C, U, D + sub-action | An event file is created, changes or is deleted. | | `FILE_PROCESSING_SETTINGS` | C, U, D | File processing settings change. | | `REPROCESS` | C, U | An event reprocess is created and as it progresses. | | `ALERT_RULE` | C, U, D | An alert rule changes. | | `ALERT` | C | An alert rule raises an alert. | ### Wallets and credits | Object type | Actions | Fires when | | ------------------- | ------- | ------------------------------------------ | | `WALLET` | C, U, D | A wallet changes. | | `WALLET_TYPE` | C, U, D | A wallet type changes. | | `CREDIT_TYPE` | C, U, D | A credit type changes. | | `AUTO_TOPUP_CONFIG` | C, U, D | An automatic top-up configuration changes. | ### Workflows | Object type | Actions | Fires when | | --------------------------- | ------- | --------------------------------------------------- | | `WORKFLOW` | C, U, D | A workflow changes. | | `WORKFLOW_ACTION` | C, U, D | A workflow action changes. | | `WORKFLOW_TRIGGER` | C | A workflow fires. | | `WORKFLOW_ACTION_EXECUTION` | C, U | A workflow action runs and when its status changes. | ### Reports and bulk actions | Object type | Actions | Fires when | | ------------------------- | ------- | ------------------------------------------------------ | | `REPORT` | C | A report is generated. | | `REPORT_GENERATE_REQUEST` | C, U | A report generation is requested and as it progresses. | | `REPORT_SUBSCRIPTION` | C, U | A report subscription changes. | | `REPORT_CONFIGURATION` | C, U | A report configuration changes. | | `REPORT_DEFINITION` | C, U | A report definition changes. | | `BULK_ACTION` | C, U | A bulk action is created and as it progresses. | ### Platform and integrations | Object type | Actions | Fires when | | ------------- | ------- | --------------------------------------------------------------------------------------------- | | `PLATFORM` | C, U, D | Your platform settings change. | | `INTEGRATION` | C, U, D | An integration changes. | | `WEBHOOK` | C, U, D | A webhook configuration changes, including when Solvimon disables it after repeated failures. | > **Warning** > > `GET /v1/webhooks/actions` returns `WALLET_GRANT`, `PAYMENT_SCHEDULE`, `PAYMENT_REQUEST` and `PORTAL_URL`, and the API accepts them in `included_actions`. Solvimon does not send events for them yet. ## Via Desk In the Desk sidebar, go to **Developers → Webhooks**. When you create or edit a webhook, use **Add included action** and **Add excluded action**. Select an object type, and then select one or more of its actions. The lists come from `GET /v1/webhooks/actions`, so they always include every sub-action on this page. ## Edge cases * **Ordering across event names is not guaranteed.** One change can produce several deliveries, for example `INVOICE.STATUS_TO_FINAL`, `INVOICE.PAID` and `INVOICE.UPDATED`. Process each one on its own and use `data` as the current state. * **Duplicates are possible.** Solvimon can retry or resend a delivery, so make your handler idempotent. For example, check the resource's current state before you act. * **Sub-actions are not implied.** If you list only base actions, you will not receive transition events, and vice versa. * **Old event names.** `INVOICE.FINALIZED`, `invoice.finalized` and other lowercase names do not exist. Event names are always uppercase. ---