Offline Checkouts

Devices that activate a pooled license in an offline or air-gapped environment cannot call the License API for each individual consumption. To handle this, the pool lends a budget upfront: at offline activation the device reserves a block of units from the pool (a checkout), consumes locally against that reservation, and settles the difference when it reconnects or deactivates.

Reservation Lifecycle

1. Offline Activation

When a device activates a pooled license offline, the License API creates a checkout and immediately debits the reserved units from the pool, marking them as held. The number of units reserved follows this priority:

1. The amount specified in the activation request, if provided.
2. The license's own effective consumption limit.
3. For members with unlimited consumptions, the pool's Default offline checkout value.

The Default offline checkout value applies only to members with unlimited consumptions. For members with a defined cap, the license or feature's own effective consumption limit is used instead.

2. Offline Usage

The device consumes locally against its reservation. The application does not need to know the reservation size, the license file carries the maximum the device is permitted to spend.

3. Re-activation

If the same device offline-activates the same license again while its checkout is still open, the existing checkout is reused and no additional units are reserved.

4. Sync or Deactivation

When the device syncs its offline usage or deactivates, the checkout is settled. The reported consumption remains spent, it is added to the member's contribution and stays in the pool total, and every unreported unit is returned to the pool.

Example: On a 10,000-unit pool, a device reserves 5,000 units at offline activation. The pool shows 5,000 held. The device consumes 700 offline and deactivates. 700 units remain consumed (the license's contribution increases by 700), and 4,300 units are returned to the pool.

A checkout is an accounting reservation, not a guarantee of real usage. While a checkout is open, its units are unavailable to any other member that is the guarantee the offline device needs. A pool can legitimately appear fully used while most of its balance is simply held by offline devices waiting to sync.

Where Checkouts Appear in the Platform

The pool detail page presents the offline picture in three places:

Balance card: The Held by offline checkouts striped segment inside the usage meter, and the Held offline stat displayed alongside Available to spend now.

Members table: A Held offline column showing the units each member's devices are currently holding.

Offline checkouts table: one row per open or settled device reservation, showing: created on, device, license (and feature for feature-typed pools), checked out, consumed, returned, still held, last sync, and a status of Held or Synced.

All three surfaces are consistent: the held stat equals the sum of the Still held column across rows, and a member's Held offline figure equals the total of its devices' still-held units.

Feature-Typed Pools

Feature pools work identically to license pools. Offline activation reserves units per pooled feature, creating one feature checkout per feature. Sync settles each one individually. The checkouts table in a feature pool includes the feature alongside the license and device.

Integration Notes

• Checkout events are published to your webhook subscriptions a *.checked_out event when a reservation is created, and a *.synced event with the consumed and returned amounts when it settles. See Webhooks and Notifications.
• Checkout rows are available via the Management API, including a filter for open versus settled reservations. See Management API Reference.

Error Behavior for Unlimited Members

When a pooled license or feature has unlimited consumptions, the pool is the only active cap. If a device attempts to reserve more units than the pool's quota allows at offline activation, the request is rejected with pool_quota_exhausted not with license_not_enough_consumptions or feature_not_enough_consumptions, since no individual cap exists on the member.