The subscription_entitlement object represents the entitlement a subscription holds for a feature. A subscription can have several subscription_entitlements, each tied to a specific feature.
When an entitlement_override is set for a subscription related to a feature, the value of the subscription_entitlement takes on the value of the entitlement_override.
If there isn't an entitlement_override, the value of the subscription_entitlement is based on the entitlements linked to the item_prices within the subscription_items. If an item_price lacks an entitlement record for a particular feature, we consider the entitlement (when available) of its parent item.
The method used to derive the subscription_entitlement from entitlements follows specific rules determined by the feature type. We outline and provide examples of these rules in the sections below:
Consider a feature of type switch. Consider also a subscription, some of whose subscription_items correspond to item_prices (or items) that have entitlements to the feature. Looking at these entitlements, we first determine the entitlement value held by each subscription_item for this feature.
If the entitlement value for the feature held by any of the subscription_items is true, then the subscription_entitlement value is also set to true. Otherwise, the subscription_entitlement value is also set to false.
Consider the following feature record:
id | type | description |
|---|---|---|
xero-integration | switch | An integration with the Xero accounting software. |
Consider the following entitlement records for the xero-integration feature:
entity_id | entity_type | value |
|---|---|---|
starter | plan | true |
starter-monthly-usd | plan_price | false |
plus | addon | true |
Consider that a subscription with id AzZjAiTl1btqS2lEj has the following subscription.subscription_items[] records:
subscription_items[] index | item_price_id | quantity |
|---|---|---|
0 | starter-monthly-usd | 1 |
1 | plus-monthly-usd | 1 |
2 | installation-usd | 2 |
Chargebee Billing now determines the entitlement held by each subscription_items[] based on the entitlements defined in Table 2. This is shown in Table 4. For clarity, we've omitted the quantity column because it doesn't affect features with the switch type.
subscription_items[] index | item_price_id | Entitlement value (determined from Table 2) |
|---|---|---|
0 | starter-monthly-usd | false (Matches the value of the plan price.) |
1 | plus-monthly-usd | true (Inherited from the addon plus, as no entitlement is defined for this addon price.) |
2 | installation-usd | None (No entitlement defined for the charge item.) |
In this scenario, the final entitlement (subscription_entitlement.value) for the xero-integration feature is set to true because at least one subscription-item entitlement value is true.
Suppose there's an entitlement_override added to the subscription for the feature, as shown below:
entity_id | entity_type | feature_id | value |
|---|---|---|---|
AzZjAiTl1btqS2lEj | subscription | xero-integration | false |
Given this override, the subscription's final entitlement value (subscription_entitlement.value) for the xero-integration feature is set to false.
Consider a feature of type quantity. Consider also a subscription, some of whose subscription_items correspond to item_prices (or items) that have entitlements to the feature. Looking at these entitlements, we first determine the entitlement value held by each subscription_item for this feature.
If the entitlement value for the feature held by any of the subscription_items is unlimited, then the subscription_entitlement value is also unlimited. Otherwise, the subscription_entitlement value is the sum of all the entitlement values of the subscription_items.
Consider the following feature record:
id | type | description |
|---|---|---|
user_licenses | quantity | The number of user licenses provided. |
Suppose that the feature has feature.levels[] records as follows:
levels[].level | levels[].value | levels[].is_unlimited |
|---|---|---|
0 | 5 | false |
1 | 10 | false |
2 | 20 | false |
3 | Not set. | true |
Consider the following entitlement records for the user_licenses feature:
entity_id | entity_type | value |
|---|---|---|
starter | plan | 10 |
starter-monthly-usd | plan_price | unlimited |
plus | addon | 5 |
one-time | charge | 5 |
Consider that a subscription with id AzZjAiTl1btqS2lEj has the following subscription.subscription_items[] records:
subscription_items[] index | item_price_id | quantity |
|---|---|---|
0 | starter-monthly-usd | 5 |
1 | plus-monthly-usd | 10 |
2 | one-time-usd | 1 |
Chargebee Billing now determines the entitlement held by each subscription_items[] based on the entitlements defined in Table 8. This is shown in Table 10.
subscription_items[] index | item_price_id | quantity | Entitlement value (determined from Table 8) | Entitlement value subtotal (Entitlement value x quantity) |
|---|---|---|---|---|
0 | starter-monthly-usd | 5 | unlimited (Matches the value of the plan price.) | unlimited (unlimited x 5) |
1 | plus-monthly-usd | 10 | 5 (Inherited from the addon plus, as no entitlement is defined for this addon price.) | 50 (5 x 10) |
2 | one-time-usd | 1 | 5 (Inherited from the charge one-time.) | 5 (5 x 1) |
In this scenario, the final entitlement value (subscription_entitlement.value) for the user-licenses feature is the total entitlement value from the last column in Table 10. Which amounts to (unlimited + 50 + 5) = unlimited.
Suppose there's an entitlement_override added to the subscription for the feature, as shown below:
entity_id | entity_type | feature_id | value |
|---|---|---|---|
AzZjAiTl1btqS2lEj | subscription | user_licenses | 20 |
Given this override, the subscription's final entitlement value (subscription_entitlement.value) for the user-licenses feature is set to 20.
Consider a feature of type range. Consider also a subscription, some of whose subscription_items correspond to item_prices (or items) that have entitlements to the feature. Looking at these entitlements, we first determine the entitlement value held by each subscription_item for this feature.
If the entitlement value for the feature held by any of the subscription_items is unlimited, then the subscription_entitlement value is also unlimited. Otherwise, one of two scenarios are possible:
If feature.levels[1].is_unlimited is true, the subscription_entitlement value equals the sum of all entitlement values of the subscription_items.
If feature.levels[1].is_unlimited is false, the subscription_entitlement value equals the sum of all entitlement values of the subscription_items without exceeding the maximum value of feature.level[1].value.
Consider the following feature record:
id | type | description |
|---|---|---|
api_rate_limit | range | The maximum number of API requests allowed per minute. |
Suppose that the feature has feature.levels[] records as follows:
levels[].level | levels[].value | levels[].is_unlimited |
|---|---|---|
0 | 100 | false |
1 | 1000 | false |
Consider the following entitlement records for the api_rate_limit feature:
entity_id | entity_type | value |
|---|---|---|
premium | plan | 450 |
premium-monthly-usd | plan_price | 400 |
plus | addon | 150 |
Consider that a subscription with id AzZjAiTl1btqS2lEj has the following subscription.subscription_items[] records:
subscription_items[] index | item_price_id | quantity |
|---|---|---|
0 | premium-monthly-usd | 2 |
1 | plus-monthly-usd | 2 |
Chargebee Billing now determines the entitlement held by each subscription_items[] based on the entitlements defined in Table 14. This is shown in Table 16.
subscription_items[] index | item_price_id | quantity | Entitlement value (determined from Table 14) | Entitlement value subtotal (Entitlement value x quantity) |
|---|---|---|---|---|
0 | premium-monthly-usd | 2 | 400 (Matches the value of the plan price.) | 800 (400 x 2) |
1 | plus-monthly-usd | 2 | 150 (Inherited from the addon plus, as no entitlement is defined for this addon price.) | 300 (150 x 2) |
feature.levels[1].is_unlimited is falseIn this scenario, the final entitlement value (subscription_entitlement.value) for the api_rate_limit feature is the total entitlement value from the last column in Table 16, capped at feature.levels[1].value. The total entitlement value is 800 + 300 equaling 1100. However, feature.levels[1].value is 1000, which is less than 1100. Therefore, the final entitlement is 1000.
feature.levels[1].is_unlimited is trueIn this scenario, feature.levels[1].value is disregarded, and the final entitlement value (subscription_entitlement.value) is not capped. In other words, the final entitlement value is 1100.
Consider a feature of type custom. Consider also a subscription, some of whose subscription_items correspond to item_prices (or items) that have entitlements to the feature.
Looking at these entitlements, we first determine the entitlement value held by each subscription_item for this feature. The subscription_entitlement value is then set to the highest of these identified values.
Consider the following feature record:
id | type | description |
|---|---|---|
support | custom | The form of after-sales support provided to the customer. |
Suppose that the feature has feature.levels[] records as follows:
levels[].level | levels[].value |
|---|---|
0 | email |
1 | chat |
2 | call |
Consider the following entitlement records for the support feature:
entity_id | entity_type | value |
|---|---|---|
starter | plan | chat |
starter-monthly-usd | plan_price | email |
plus | addon | call |
Consider that a subscription with id AzZjAiTl1btqS2lEj has the following subscription.subscription_items[] records:
subscription_items[] index | item_price_id | quantity |
|---|---|---|
0 | starter-monthly-usd | 2 |
1 | plus-monthly-usd | 2 |
Chargebee Billing now determines the entitlement held by each subscription_items[] based on the entitlements defined in Table 19. This is shown in Table 21. For clarity, we've omitted the quantity column because it doesn't affect features with the custom type.
subscription_items[] index | item_price_id | Subscription-Item Entitlement Value (determined from Table ) |
|---|---|---|
0 | starter-monthly-usd | email (Matches the value of the plan price.) |
1 | plus-monthly-usd | call (Inherited from the addon plus, as no entitlement is defined for this addon price.) |
In this scenario, the final entitlement (subscription_entitlement.value) for the support feature is the highest of all the subscription-item entitlement values, which in this case is call.
Suppose there's an entitlement_override added to the subscription for the feature, as shown below:
entity_id | entity_type | feature_id | value | expires_at |
|---|---|---|---|---|
AzZjAiTl1btqS2lEj | subscription | support | chat | 1695884985 (7 days from now, assuming today is 2023-09-21.) |
Given this override, the subscription's final entitlement value (subscription_entitlement.value) for the support feature will be chat until 2023-09-21 and call thereafter.
{
"subscription_entitlement": {
"subscription_id": "Azq8g8ULPXqdL6zM",
"feature_id": "xero-integration",
"feature_name": "Xero Integration",
"feature_type": "SWITCH",
"value": "true",
"name": "Available",
"is_overridden": true,
"is_enabled": true,
"object": "subscription_entitlement"
}
}type is either quantity or range. The value denoting the final entitlement level that the subscription holds for the feature.
type of feature as follows: feature.type is range or quantity: the name is the space-separated concatenation of value and the pluralized form of feature_unit. For example, if value is 20 and feature_unit is user, then name becomes 20 users.feature.type is custom: the name is the same as value.feature.type is switch: name is set to Available when value is true; it's set to Not Available when value is false.entitlement_overrides record. Retrieves the list of subscription_entitlements for the subscription.
Note:
The components attribute is not returned for any of the subscription_entitlements. Use the retrieve operation(coming soon) to obtain the components.
Enables or disables specific subscription_entitlements for a subscription.