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:

Event	Fires when
license.consumption_added	A license consumes (pooled or standalone)
license.consumption_max_reached	A license reaches its own effective limit
license_product_feature.consumption_added	A product feature consumes
license_product_feature.consumption_max_reached	A feature reaches its own effective limit
consumption_pool.consumption_added	A pool's balance increases
consumption_pool.consumption_max_reached	A pool reaches its effective limit (maximum plus overage allowance, where applicable)
consumption_pool_license_checkout.checked_out	A device reserves units from a pool at offline activation
consumption_pool_license_checkout.synced	A device's checkout settles on sync or deactivation
consumption_pool_license_feature_checkout.checked_out	Feature-pool equivalent of the above
consumption_pool_license_feature_checkout.synced	Feature-pool equivalent of the above

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.

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.

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

Example consumption_pool_license_checkout.synced

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

{
  "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.