Skip to main content
An entitlement is an access right a customer holds because of their subscription: a feature that is on, a quota such as seats or included storage, a named tier, or a recurring credit allocation. Entitlements are defined on plans and subscription versions alongside the prices, and your application reads them back through the API to decide what the customer can do. Use them for gating and provisioning; use billable metrics and credits for measuring and charging consumption. See How Alguna Works for where entitlements sit in the object graph.

What an entitlement is

An entitlement is a key, a type, a mode and a value, attached to a subscription version: A credit_allocation entitlement carries an allocation (amount, credit_type of monetary or units, rollover_enabled and an optional rollover_max_periods) and a timing (recurrence of recurring or one_off, with an interval of monthly, quarterly, semi_annual or yearly). Alguna does not meter your application’s usage against an entitlement. Your application asks what the customer is entitled to and enforces it. To bill or limit by consumption, send usage events and use a credit-allocation entitlement when the customer should draw down an included balance.

Defining entitlements

Entitlements travel with the offer, so they are set where the offer is defined:
  • On a plan — the entitlements array on Create a plan, or when building the plan in the dashboard. Every subscription created from the plan inherits them.
  • On a subscription version — the entitlements array on Create a new subscription version or Replace a draft subscription version (the full set for that version), or the subscription editor in the dashboard. Use this to grant one customer something their plan does not.
Each entry is an entitlement_key, type, mode and (for scalar types) value:
Entitlements take effect when the version is published. Until then they belong to a draft.
Reusable entitlement configs, templates, and the transition policies that decide what happens to active grants when a version changes are managed in the dashboard under Entitlements. The public API sets entitlement values on plans and versions and reads them back; it does not manage configs or policies.

Reading entitlements

Three endpoints answer “what can this customer do?”.

One entitlement on a subscription

Get a specific entitlementGET /subscriptions/{id}/entitlements/{key}
Response

All entitlements on a subscription

List active entitlementsGET /subscriptions/{id}/entitlements returns every entitlement on the subscription’s current published version, static and grant-based.

All entitlements for a customer

List active entitlements for a customerGET /customers/{id}/entitlements flattens the entitlements across all of the customer’s active subscriptions. Each entry carries the subscription_id it came from. The {id} accepts the Alguna customer ID, one of the customer’s aliases, or a connected-account external ID such as a Stripe customer ID, so you can call it with the identifier you already hold.
value is always returned as a string, whatever the entitlement’s type. Parse it according to type. An entry with a null subscription_id and version_id comes from your organization’s default entitlement profile rather than from a subscription.

Checking access in your application

Cache the result for the length of a session rather than calling on every request. Entitlements change only when a subscription version is published, and a subscription.version.updated webhook fires when that happens, so you can invalidate on the event.

Credit allocations

For a credit_allocation entitlement, the entitlement tells you what was allocated; the balance and the draw-down live in the credits API. Check the remaining balance before allowing consumption with GET /subscriptions/{id}/credits/balance:
To reserve credit before doing expensive work and settle it afterwards, use the realtime gate described in Credit Consumption.

Version changes

When a subscription moves to a new version, its transition policy decides what happens to grant-based entitlements that are being replaced: Transition policies are configured per version change in the dashboard and previewed before the change is published. See Versioning and Amendments.

Best practices

Use stable keys

Your application reads entitlements by key. Keep keys identical across plans so an upgrade never needs a code change.

Meter separately

Entitlements describe access. Bill consumption with metrics and credits.

Cache reads

Entitlements only change when a version is published; invalidate on subscription.version.updated.

Fail closed

Treat a missing entitlement (404) as no access, not unlimited access.

Next steps

Plans

Define entitlements once on the offer.

Subscription Versioning

Entitlements are read from the current published version.

Credits & Wallets

Meter and draw down credit allocations.

Webhooks

Invalidate caches when versions change.