The following terms are referred to within the context of Elastic Access:
This section provides a broad definition of tokens. Producers using FlexNet Operations as their back office are also advised to read the information under Token Structure When Using FlexNet Operations.
Tokens represent flexible entitlements to technology offerings. Each offering has an associated token value. Customers are charged tokens for the technology offerings they use.
Tokens in the context of Elastic Access are metered tokens, which means they are consumed from line items until there are none remaining. Once consumed, a new line item count must be sold to the end customer to replenish the available tokens. Alternatively, an overdraft may be set on the line item. This can be either a specific overdraft limit, or an unlimited overdraft.
For procedural information about allowing an overdraft, see the topic Creating a License Model in the FlexNet Operations User Guide. Producers who use a back office other than FlexNet Operations can set the overdraft directly in the /line-items API (see Map a line item to an instance in the Dynamic Monetization API Reference).
Tokens allow customers to:
- Access any item in your portfolio based on token cost.
- Scale usage dynamically—ideal for seasonal or project-based demand.
This model supports cross-portfolio access and on-demand capacity, which is especially valuable for AI-driven features, simulations, or compute-heavy services.
Instead of managing SKUs for every feature, you:
- Sell tokens upfront (prepaid consumption).
- Define token costs in a rate table (see also Rate Tables).
- Let customers consume based on need.
This reduces friction in packaging and pricing, and accelerates speed-to-market.
Every token consumed is tracked with metadata:
- What was used
- Who used it
- Where and how it was used
This enables customer value intelligence, P&L alignment, and targeted upsell/cross-sell strategies.
Tokens support:
- Pay-as-you-go or pay-per-use models.
- Overdraft options (e.g., allow usage beyond token balance).
- Hybrid models (e.g., subscription + token-based expansion).
You can even offer free tokens to drive adoption or reward loyalty
Wherever the word “token” is used in this document, it means “metered token”. There is no provision for any other kind of token in Elastic Access.
This topic describes a line item in the context of Elastic Access. Producers who use FlexNet Operations as their back office should also read the definition under Elastic Access Line Item, which explains the difference between the line item concept that users are familiar with from FlexNet Operations and line items in Elastic Access.
In the remainder of this document, the terms “Elastic Access line item” and “line item” are interchangeable. Both refer to line items that can be mapped to an Elastic Access instance.
A line item captures an entitlement to a number of tokens which have been sold to an end customer, and which will be made available through an Elastic Access instance.
A line item will be automatically mapped to an Elastic Access instance accessible to the end customer (only one instance may be used for an end customer—if a customer has multiple line items for Elastic tokens, these will all be mapped to the same instance).
A producer can set up an overdraft when creating or modifying a line item using the /line-items API (see Map a line item to an instance in the Dynamic Monetization API Reference).
An item represents something offered by a producer, which customers can access in exchange for tokens. An item can be a product, or feature, or some other technology resource for which tokens can be charged. Each item is assigned a rate that defines how many tokens are charged for the item (see also Rate Tables).
Rate tables are used to define the price of items (how many tokens are charged per item).
In Dynamic Monetization, rate tables play a pivotal role in enabling flexible, usage-based pricing models especially relevant for software and connected device businesses. At their core, rate tables define how many tokens (or credits) a customer must spend to access specific features, services, or products. Think of them as dynamic price lists that power Elastic Access models, where customers pre-purchase tokens and consume them based on usage.
Rate tables allow product teams to adjust pricing instantly without needing to redeploy entitlements or licenses. This means you can:
- Respond to market shifts or customer feedback in real time.
- Launch promotions or tiered pricing without engineering changes.
A rate table is defined by the following elements:
- Effective Date—The date after which the rate table will be used to calculate token charges. Elastic Access always uses the rate table with the most recent effective date (if more than one version exists).
- Version—Providing different versions of a rate table gives a producer the flexibility to change prices over time, or vary the products and services it contains, while keeping a record of historic prices. Providing a version is mandatory, but it is for the producer’s or end customer’s benefit; Elastic Access does not use the version to determine which rate table to use.
- Series—A rate table may also be defined by a series, which is an optional property. Series are a way to group rate tables. This might be useful, for example, to introduce new prices for a new financial year, or for different divisions within a producer's organization to maintain their own rate tables. Each series will have its own sequence of versions.
If no series is defined, the rate tables form a single time-based sequence. - Items—An item represents an offering that customers can access in exchange for tokens. An item is defined by a name and an optional version. Each item is assigned a rate that defines the “price” of the item.
The following is an example of what a rate table might look like:
| Element | Child element | Type | Sample Value |
|---|---|---|---|
| effectiveFrom | n/a | number | 1693145037000 See Time Fields in Dynamic Monetization for time format information. |
| version | n/a | string | 1 |
| series | n/a | string | PublicationApps |
| items | name | string | PhotoPrint |
| version | string | 1.0 | |
| rate | number | 3 | |
| items | name | string | SignPrint |
| version | string | 1.0 | |
| rate | number | 4 | |
| items | name | string | CADPrint |
| version | string | 2.0 | |
| rate | number | 7 |
Rate table series are a way to associate different sequences of versions together. For a given series (which might be called, for example, “series1”) a sequence of versions of that series could be released over time, giving producers the opportunity to adjust prices within the series or add new technology offerings. If it was decided to “reset” the pricing structure, a new series (for example, “series2”) could be started for subsequent entitlements. For such sequential series, dates might be used for the series name.
Alternatively, several series could be operated in parallel with distinct groups of technology items, separating them for individual marketing purposes, or to support different divisions within a single producer organization.
The following diagram visualizes the relationship between versions and series:
For detailed information about the rate table structure and its elements, refer to the API Reference.
An application or software running on your customer’s site, or running in the cloud as a SaaS (Software as a Service) application provided to your customer, will use items (a product, or feature, or some other technology resource) for which tokens can be charged. Each time these resources are used, a call—termed an access request—is made to Elastic Access to request use of the item so that the number of tokens required can be calculated and charged to an available line item. In addition, an entry is sent to the Data Warehouse to register that usage for analytics purposes.
There are two ways an access request can be made:
- As a one-off request, see One-Off Access Requests.
- As part of a session to achieve repeated scheduled charges, see Session-Based Access Requests.
A one-off request for use of items is achieved using the elastic/api/v1.0/instances/{instanceId}/access-request endpoint of the Dynamic Monetization REST API (see Access request for elastic tokens). One-off requests can be useful in the following scenarios:
- You are experimenting with Elastic Access concepts.
- An application allows an item to be used once only, where activity is not time-based.
For an example that demonstrates a call to /access-request, see Exercise 4a: Running a One-Off Access Request.
If multiple items are requested in this one-off way, Elastic Access attempts to fulfill the request in the order the items are specified. If it cannot fulfill all items requested, it will make a “best effort” fulfillment. This includes:
- Charging for as many items as possible in the order in which they were requested.
- Sending a success response for items that could be fulfilled.
- Returning an error response for the items that could not be fulfilled.
A client application can make access requests as part of a session. A session is a timeline where a customer is repeatedly charged for using one or more items. During this period, the client application does not need to repeat its access requests to Elastic Access (although it may change the combination of items it is using at any time or notify that it has finished using them).
The client application makes a session-based access request by sending a PUT to the /api/v1.0/sessions/{sessionID} endpoint. The endpoints used to initiate and manage sessions and the session workflow are discussed briefly in the Sessions section and in more depth in the Managing Sessions.
For an example that demonstrates a call to /api/v1.0/sessions/{sessionID}, see Exercise 4b: Running a Session-Based Access Request.
Access requests can be made as part of a session. This allows the following:
- Repeating, sequencing, or varying a number of activities over a period.
- Charging tokens repeatedly at regular intervals so that total charges are proportional to the duration of use.
- Ensuring that the software can continue extended use of items over an extended period without having to repeat requests to Elastic Access at precisely the right time.
- Charging for repeated use up-front rather than retrospectively, therefore avoiding “extending credit” to the customer
Sessions are initiated, managed, and terminated programmatically by the client application that makes an access request. Actions related to sessions are performed using the /api/v1.0/sessions endpoint of the Dynamic Monetization REST APIs (see Request a new session).
Sessions are described in detail in a separate section, Managing Sessions.
In Dynamic Monetization, rules of access are used to control the way the count of an elastic line item is used in an access request. These rules allow your customers to create and enforce policies that regulate token consumption from elastic line items within your Dynamic Monetization environment. The rules determine by who or where tokens can be consumed, based on specific conditions.
Rules of access are described in detail in a separate section, Rules of Access.