For example, if you were a fitness company you might choose to gate your content based on workout type. Assuming you had yoga, meditation, and HIIT content, you could offer these a la cart, or via a bundle. However, there would be three entitlements (one for each workout type). You could then define individual plans that grant access to one or more of these entitlements based on your pricing strategy.

Or perhaps you separate your content into two buckets: basic and premium. You can define these as the two entitlements in Revenue HQ and then make the determination of what each entitlement unlocks on your side.

When your servers make an API call to Revenue HQ to see what access an account has, the array of entitlements associated with their current subscription will be returned. These are meaningless to Revenue HQ; they are simply returned back to you on a per-account basis so your system knows which features to enable for an individal account.

We recommend setting fine-grained entitlements and then using plans to bundle multiple entitlements together. Continuing the fitness example, it is easier to reason about a plan that gives entitlements to "yoga" and "meditation" than it is to reason about a plan that gives an entitlement called "basic".

While entitlements can be defined when creating an application, once an application exists they are modified using dedicated REST endpoints. Note that entitlements aren't updated; rather you can create new entitlements and delete previous ones.

NOTE: Entitlements are case-insensitive. Before storing them in the database, we remove all leading and trailing white spaces, and convert the string to lowercase. EnTiTlEmEnT will be saved in our system, and returned to yours, as entitlement.