> For the complete documentation index, see [llms.txt](https://docs.licensespring.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.licensespring.com/consumption-pools/webhooks-and-notifications.md).

# Webhooks and Notifications

Pooled consumption emits webhook events you can subscribe to, along with one email notification policy.

### Event Catalog

Ten event codes cover pooled metering:

<table data-search="false"><thead><tr><th>Event</th><th>Fires when</th></tr></thead><tbody><tr><td><code>license.consumption_added</code></td><td>A license consumes (pooled or standalone)</td></tr><tr><td><code>license.consumption_max_reached</code></td><td>A license reaches its own effective limit</td></tr><tr><td><code>license_product_feature.consumption_added</code></td><td>A product feature consumes</td></tr><tr><td><code>license_product_feature.consumption_max_reached</code></td><td>A feature reaches its own effective limit</td></tr><tr><td><code>consumption_pool.consumption_added</code></td><td>A pool's balance increases</td></tr><tr><td><code>consumption_pool.consumption_max_reached</code></td><td>A pool reaches its effective limit (maximum plus overage allowance, where applicable)</td></tr><tr><td><code>consumption_pool_license_checkout.checked_out</code></td><td>A device reserves units from a pool at offline activation</td></tr><tr><td><code>consumption_pool_license_checkout.synced</code></td><td>A device's checkout settles on sync or deactivation</td></tr><tr><td><code>consumption_pool_license_feature_checkout.checked_out</code></td><td>Feature-pool equivalent of the above</td></tr><tr><td><code>consumption_pool_license_feature_checkout.synced</code></td><td>Feature-pool equivalent of the above</td></tr></tbody></table>

{% hint style="warning" %}
**Twin emission is intentional.** A single consumption on a pooled member emits both a member event (`license.consumption_added` or its feature equivalent) and a pool event (`consumption_pool.consumption_added`). If you are aggregating usage from webhook events, count only one of the two, not both. Similarly, an offline deactivation emits both the consumption events for the usage being reported and the `*.synced` checkout event.
{% endhint %}

### Payload Shape

All events use the standard LicenseSpring history-event envelope `id`, `event`, `company_id`, `timestamp`, and `initiator`  with a `data` object made up of the following sections. Sections with no data for a given event are omitted from the payload.

<table data-search="false"><thead><tr><th>Section</th><th>Present on</th><th>Contents</th></tr></thead><tbody><tr><td><code>license</code></td><td>License and checkout events</td><td>License state: totals, limits, key, order, and product</td></tr><tr><td><code>license_product_feature</code></td><td>Feature and feature-checkout events</td><td>Feature state</td></tr><tr><td><code>consumption_pool</code></td><td>Pool and checkout events</td><td>Pool state <code>total_consumptions</code> is the authoritative post-write pool total</td></tr><tr><td><code>consumption_pool_checkout</code></td><td>Checkout events</td><td><code>checked_out</code>, <code>consumed</code>, <code>returned</code>, <code>synced_at</code></td></tr><tr><td><code>device</code></td><td>Consumption and checkout events with a device</td><td>Device identification</td></tr><tr><td><code>license_user</code></td><td>When the license has an assigned user</td><td>User identification</td></tr><tr><td><code>consumption_info</code></td><td>Consumption events</td><td>The amount and context of this consumption</td></tr><tr><td><code>request_info</code></td><td>All events</td><td>SDK version, source, and request context</td></tr></tbody></table>

#### Example `consumption_pool_license_checkout.synced`

The following payload is emitted when a device that reserved 5,000 units reports 700 consumed on sync:

```json
{
  "event": "consumption_pool_license_checkout.synced",
  "company_id": 376,
  "ts": "2026-09-15T09:21:29.788Z",
  "data": {
    "license": {
      "id": 1790242270029099,
      "license_key": "URCA-2JZ6-BHXJ-V9LK",
      "total_consumptions": 1900,
      "max_consumptions": 5000
    },
    "consumption_pool": {
      "id": 2,
      "name": "AI Credits",
      "type": "license",
      "total_consumptions": 3900,
      "max_consumptions": 10000
    },
    "consumption_pool_checkout": {
      "checked_out": 5000,
      "consumed": 700,
      "returned": 4300,
      "synced_at": "2026-09-15T09:21:29.788Z"
    },
    "device": {
      "hardware_id": "HW-DEVICE-01"
    },
    "request_info": {
      "sdk_ver": "8.9.0"
    }
  }
}
```

A `*.checked_out` event carries the same sections with `{"checked_out": 5000, "consumed": 0, "returned": 0, "synced_at": null}` and reflects the pool total immediately after the reservation debit.

**Additional notes:**

* No checkout event fires when a re-activation reuses an existing open checkout, no new reservation was made, so nothing is emitted.
* Events are published after the transaction commits. A failed request emits no events.

### Email Notification

The **Max pool consumptions reached** (`max_pool_consumptions_reached`) notification policy sends an email when a pool reaches its cap. This coexists with the license-level **Max consumptions reached** notification, a pooled member can trigger its own cap notification independently of the pool's.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.licensespring.com/consumption-pools/webhooks-and-notifications.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.