Have a verified Customer and Feature requirement. Reads/checks inform presentation; consumption before protected work remains on the trusted backend.
Feature access & Paywalls
Current feature definitions, access checks, purchase recommendations and verified rechecks.
API v1Updated
Before you start
Access checks and consumption
readHoldings presents the current Customer's holdings/balances. Where enabled, checkEntitlement returns an explicit access result; use the current requirement schema. UI visibility, a true Feature Flag, Paywall display or purchase completion does not replace backend authorization.
Before protected work, atomically consume or reserve through backend mutateBalance. Confirm actual usage after asynchronous completion or release on failure. If access evaluation is unavailable, show the explicit error rather than assuming approval.
When a purchase is needed
If a purchase can satisfy the unmet access requirement, present a published standalone Paywall. Re-read actual access after purchase before continuing the original task.
Related:Paywall·checkEntitlement API
HTTP operations
Use these operations with your HTTP integration. Each reference includes complete request/response fields and credential requirements; SDK snippets are an alternative when a matching SDK is available.
| Operation | HTTP | Permission |
|---|---|---|
| checkEntitlement | POST /api/v1/entitlements/check | entitlements:read |
| mutateBalance | POST /api/v1/balances/execute | credits:consume |
Operation and permission
checkEntitlement
- HTTP
- POST /api/v1/entitlements/check
- Permission
- entitlements:read
mutateBalance
- HTTP
- POST /api/v1/balances/execute
- Permission
- credits:consume
Related:checkEntitlement·mutateBalance
Check your result
Expected outcome
Continue when allowed, present a Paywall when purchase can satisfy the requirement, and preserve reasons for limits, authentication or configuration failures.