Skip to main content
Retrieves a specific entitlement for a customer, checking their access to a particular feature or custom credit currency.
To benefit from Stigg’s low-latency capabilities, use the Sidecar — it serves entitlement checks from a local cache without a network round-trip per request, with built-in fallback handling. For Node.js applications, the Node.js SDK provides equivalent low-latency caching natively in-process.
The entitlement query is deprecated. Use entitlementV2 instead — it accepts either featureId or currencyId on the same query, so it can resolve both feature entitlements and credit entitlements (polymorphism support). New integrations should use entitlementV2.

Query

Passing options.requestedUsage evaluates the check against a specific amount of usage before it’s consumed — the recommended way to gate an action. See Checking, gating, and reporting usage for the full pattern.

Parameters

FetchEntitlementQuery
required
Query parameters for fetching the entitlement

Return Type

entitlementV2 returns a union of FeatureEntitlement or CreditEntitlement, depending on whether the query was made with featureId or currencyId. Select fields for each type using inline fragments (... on FeatureEntitlement, ... on CreditEntitlement). Fields common to both: FeatureEntitlement-only fields: CreditEntitlement-only fields:

Access Denied Reasons

Common Use Cases

Check access before showing/enabling a feature.
Verify if customer can perform an action based on usage limits.
Check limits to show upgrade prompts when approaching limits.

Example: Check Before Action

Checking with requestedUsage set to the exact amount you’re about to consume is what makes the gate accurate — checking currentUsage >= usageLimit against a stale cached value, or reporting usage before gating, can let one extra request through on a hard limit. See Checking, gating, and reporting usage for details.