Consumption Limits

In Elastic Access, consumption limits enable end customers to control how quickly requesters consume Elastic Tokens within a defined time period for a particular line item or for an instance or for both. They act as an important budgetary and governance mechanism, helping organizations align token usage with internal budgets, operational policies, and the intended consumption cadence of their purchased entitlements.

Consumption Limits are designed to:

• Provide budgetary control by preventing accelerated token depletion that could lead to unplanned renewal costs or operational interruptions.
• Regulate user behavior by pacing access and consumption, especially in environments with large or dynamic user populations.
• Protect against misuse or misconfiguration, ensuring that no single user or process unintentionally consumes the majority of allocated tokens.
• Align consumption with contractual expectations, allowing end customers to distribute usage evenly across periods such as months, quarters, or project phases.

For example, a consumption limit may be configured as 100 tokens per month, next reset on 2026-03-01 00:00:00. With this limit, each individual requester is restricted to consuming 100 tokens in each month, and when they have reached 100 tokens they will not be able to consume any more in that month. On 2026-03-01 their consumption total will be reset to zero, and they can begin consuming tokens again. Because the interval is stated as monthly, the reset will always happen on the first day of the month, irrespective of how many days each month has.

Consumption limits are enforced automatically on a per-requester basis and can be configured at different levels:

In Elastic Access, line-item consumption limits allow end customers to regulate how quickly requesters consume tokens associated with a specific line item.

A line-item consumption limit is enforced independently for each requester and applies only to the selected line item.

Instance-level consumption limits cap the total number of Elastic Tokens a requester can consume across an entire instance within a defined time period.

Unlike line-item limits, instance limits aggregate consumption across all line items in the instance. They are enforced automatically per requester, reset on a configured schedule, and prevent any individual user from exceeding their allocated token budget for the instance. By applying instance-level controls, organizations can manage shared token budgets more predictably while simplifying administration.

Combined line-item and instance consumption limits provide layered control over token usage. Line-item limits regulate consumption for individual entitlements, while instance limits cap total consumption across all line items. Together, they help organizations enforce budgets, prevent overuse, and maintain predictable consumption patterns.

The following examples illustrate how consumption limits are evaluated for individual requesters. In each example, the requester attempts to consume Elastic Tokens, and FlexNet Operations determines whether the request is allowed based on the configured consumption limits. These examples demonstrate how limits are enforced when configured at the line-item level, the instance level, or both levels together.

• Scenario 1: Line-Item Limit Only
• Scenario 2: Instance Limit Only
• Scenario 3: Combined Line-Item and Instance Limit

An enterprise customer administrator configures consumption limits for individual line items and does not define an instance-level consumption limit. Each line item is evaluated independently.

On May 4th, user Carol consumes tokens from multiple line items:

• Line item 1: 15 tokens consumed (out of 20 tokens allowed per day)
• Line item 2: 10 tokens consumed (out of 10 tokens allowed per day)

What Happens Next?

If Carol attempts to consume 1 additional token from line item 2 on May 4th, the request is rejected.

Reason

Carol has already reached the maximum daily consumption limit for line item 2. Although the request for line item 2 is rejected, Carol can still consume up to 5 additional tokens from line item 1 because that line item has not yet reached its configured limit.

Reset Behavior

Consumption automatically resets at the configured interval (in this case, daily). After the reset, Carol can again consume tokens up to the configured limit for each line item.

The following diagram illustrates the request flow and limit enforcement behavior for this scenario. Because only line-item limits are configured, each line item is evaluated independently. A request is denied only when the specific line item's limit is reached.

An enterprise customer administrator configures an instance-level consumption limit and does not define any line-item limits.

Within instance 1, user Chris consumes tokens across multiple line items:

• Line item 1: 10 tokens
• Line item 2: 50 tokens
• Line item 3: 40 tokens

At This Point

Total consumption is calculated across all line items in the instance. Therefore, 100 out of 100 tokens are used on instance 1. There are no line-item limits to evaluate.

What Happens Next?

If Chris attempts to consume any additional tokens from another Line item during the same month, the request will be rejected.

Reason

Chris has reached the maximum monthly consumption limit for the instance.

Reset Behavior

Consumption automatically resets at the start of the next configured period (in this scenario, at the beginning of the month).

After the reset, Chris can again consume up to 100 tokens for that instance.

An enterprise customer is entitled to consume up to 25 tokens per day for an Elastic Access instance. Within the instance, two line item-limits are configured.

Within instance 1, user Mo consumes tokens across multiple line items:

• Line item 1: 10 tokens
• Line item 2: 15 tokens

At This Point

• Line item 1: 10 tokens consumed (out of 10 tokens allowed per day)
• Line item 2: 15 tokens consumed (out of 20 tokens allowed per day)
• Instance: 25 tokens consumed (out of 25 tokens allowed per day)

What Happens Next?

Even though line item 2 still has remaining capacity (15/20 used), the overall instance limit of 25 tokens per day has been reached.

What Happens Next?

If Mo attempts to consume any additional tokens, the request will be rejected.

Reason

Mo has already reached the maximum daily consumption allowed for the instance.

Reset Behavior

Consumption automatically resets at the configured interval (in this example, daily). After the reset, Mo can again consume tokens within both the line-item and instance limits.

Configuring consumption limits typically involves the following steps:

1. Identify the line item and/or instance
   Determine which line items, instances, or combination of both require consumption control. This is often based on customer budget expectations, historical consumption trends, or contractual limits.

2. Define the limit parameters
   Consumption limits require the following:

   • Total consumption allowed per user or requester
   • The interval over which consumption is tracked
     resetFrequency Parameter

     The resetFrequency parameter used to define the tracking interval is independent of the resetFrequency parameter used for line item replenishment, which determines how often consumed tokens are restored to the end customer's full entitlement (described in Resettable Line Items).

   • The date on which consumption tracking will be counted from. This is configured in the API in milliseconds, and so a precise UTC date and time can be specified.

3. Submit the limit configuration
   Use the /consumption-limits API to create or update the limit for the selected line item and/or instance. The configuration becomes active immediately upon acceptance.

4. Monitor usage against the limit
   Customers can retrieve real-time consumption and requester-level breakdowns using the /requesters API. This visibility enables proactive management before limits are reached.

5. Adjust or remove limits as needed
   Consumption limits can be updated to reflect new budgets, usage patterns, or business decisions.

There is no need to specify which users or requesters the limits apply to. The consumption is automatically tracked for a requester as soon as the first access request is received for that requester within a given time period. The requesters API reports which requesters are being tracked in a given time period, and their consumption since the last reset date. If a requester has not made an access request in a given time period, they will not be included in the /requesters API.

When transactions are recorded in the Data Warehouse, information about applicable consumption limits is included in the transaction record. This information is stored in the REQUESTER_LIMITS field and can be used to understand how usage relates to configured consumption controls and to report on requester-level consumption against both line-item and instance-level limits.

When configuring consumption limits, keep the following in mind:

• Impact on end-user access
  Once a limit is reached, subsequent access requests will be denied unless the limit is raised or removed. Ensure that limits align with expected usage to avoid service disruption.

• Lifecycle timing
  Setting limits too low at the start of a line item may unnecessarily block legitimate consumption. Conversely, setting them too high may provide insufficient budget protection.

• Multi-user environments
  In scenarios with many users, consumption can scale rapidly. Consider implementing conservative limits initially and refine them as usage patterns become clearer.

• Reporting alignment
  Consumption reporting reflects both successful and rejected attempts. Monitoring these metrics helps customers tune limits for optimal operational efficiency.

• Change management
  Adjusting limits mid-cycle should be communicated to impacted stakeholders to ensure predictable access behavior.