> 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/offline-checkouts.md).
# 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.
{% hint style="info" %}
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.
{% endhint %}
#### 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.
{% hint style="info" %}
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.
{% endhint %}
### 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.
---
# 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/offline-checkouts.md?ask=&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.
