The business_entity resource represents a business unit or brand under your organization. Key resources in Chargebee Billing (such as customer, subscriptions, invoices, and transactions) along with the associated site configurations, fall under a business entity. Each Chargebee Billing site has one business entity by default. You may create multiple business entities in the following scenarios:
Creating multiple business entities lets you separate configuration and data for your business units or brands so that you can manage their billing and revenue operations independently.
See also
More information on business entities and the configuration options available.
All API operations in Chargebee have site context. Context restrictions cannot be assigned to API keys. However, if your site has multiple business entities, you can specify the business entity context for an API call by passing a custom HTTP request header.
The table below explains how Chargebee responds to various API calls depending on whether the business entity ID is specified as part of the API call.
Note
Some of the words used here are defined in the Terminology section.
| Operation/Type of operation | Behavior | Examples |
|---|---|---|
Any operation that creates a customer resource |
|
|
Create a resource other than customer |
|
|
| Update/delete a resource |
| |
| List resources |
| |
| Retreive a resource |
|
This section defines some useful terms for describing how business entities work.
Any resource is always associated with precisely one and only one business entity. We call it the linked business entity of the resource, or simply, the business entity of the resource.
When customer resource is created and no business entity is specified, it is linked to the business entity designated as the default business entity of the site. A site always has a default business entity. Please choose the first business entity details carefully, as it can't be changed later, and this will be your default entity when no business entity is specified.
Any site has data in it. This includes all the various resources such as customers, subscriptions, invoices, comments, and so on. The "context" of an API operation is the subset of site data it has access to. An API operation can only read or write data within its context. By default, an API operation has "site context", which means it has access to the entire site's data. However, when a business entity is specified in an API operation, it has "business entity context", which means that the operation only has access to the data linked to the business entity.
Example
Consider the List customers API. When you call the API without specifying a business entity, its context is that of the site and therefore returns customer resources for the entire site. However, when you specify a business entity, the context is only that of the business entity, and therefore the customer resources of only the selected business entity are returned.
Let's look at the Create checkout for a new subscription API. Say you're calling this API and providing the customer[id] parameter. When no business entity is specified, the operation has site context and therefore looks up the ID among all the customer resources in the site. However, when a business entity is provided, the operation has business entity context and looks up the ID only among the customers linked to that business entity.
While creating an API resource other than a customer, you specify a target resource under which it should be created. For example:
invoice resource for a one-time charge, you must specify either the customer or the subscription resource to which it belongs. The customer or subscription resource, in this case, is the target resource of the invoice.subscription, the target resource of a subscription resource is always a customer resource.quote resource of type change_subscription, the target resource is a subscription resource.{
"id": "1",
"name": "1",
"status": "active",
"deleted": false,
"created_at": 1709892529,
"updated_at": 1709892626,
"resource_version": 1709892626000,
"object": "business_entity"
}Important This API will not work if you have specified a business entity in the custom HTTP header.
Transfers one or more customer resources from one business entity to another.
The transfer is executed by creating a copy of the customer resource. The original resource is deprecated, while the new copy becomes the active resource.
Transfers must always be initiated for an active customer resources and never for a deprecated resources.
A customer resource cannot be transferred more than three times in a single calendar year. For example, if already moved thrice in the year 2023, a customer resource can only be moved again in 2024.
The customer resource must not have any of the following:
An account hierarchy relationship.
subscription resource with
status in_trial orsubscription.has_scheduled_advance_invoices as true.)invoice resource with status as pending. (Close pending invoices before invoking this API.)
invoice resources that are advance invoices. (invoice.has_advance_charges as true.)
quote resources with status as open or accepted.
transaction resource with:
status as in_progress orstatus as success, type as authorization, and a non-zero amount_capturable.Non-zero unbilled_charges. (Invoice unbilled charges before invoking this API.)
Non-zero refundable_credits. (Apply credits to unpaid invoices before invoking this API.)
The customer resource must not be a gifter of a gift subscription with status scheduled or unclaimed.
When calling this endpoint, the active and deprecated resources are processed as follows:
For the active resource:
id and active_id are set to match the deprecated resource's id.business_entity_id is set to destination_business_entity_id parameter.For the deprecated resource:
customer and subscription resources, the value of active_id is set to match the resource id.id is changed to a new random value.When this API is endpoint is called, Chargebee blocks concurrent calls to incompatible POST operations.
When a resource is transferred more than once, each transfer deprecates the previous active resource and creates a new active resource.
payment_source resources linked to the customer are immediately transferred to the destination business entity.
subscription resources linked to the customer are transferred automatically to the destination business entity as follows:
active subscription resources are transferred on their next renewal.paused subscription resources are transferred when resumed.future subscription resources are transferred on their start_date.non_renewing and cancelled subscription resources are not transferred and remain linked to the deprecated customer resource.Other resources linked to the customer, such as invoice, quote, credit_note, and transaction, remain linked to the deprecated customer resource.
Deprecated customer and subscription resources are not returned in list APIs such as List customers or List subscriptions.
See also
The following example illustrates the transfer of a customer resource from a business entity (source) to another (destination). The example also shows how payment_source, subscription, and invoice resources attached to the customer resource are affected.
Imagine a customer
resource with the id
Ab6dRFt
belonging to the business entity acme-us
. This customer has a linked payment_source
, subscription
, and an invoice
.

To transfer the customer resource to a new business entity acme-eu, you would call the endpoint as follows:
curl https://{site}.chargebee.com/api/v2/business_entities/transfers \
-u {api_key}:\
-d active_resource_ids[0]="Ab6dRFt" \
-d destination_business_entity_ids[0]="acme-us" \
-d reason_code[0]="correction"
The customer resource is deprecated in favor of a new active customer resource. Notice that the id of the deprecated customer resource is transferred to the new, active customer resource. Meanwhile, the deprecated resource is assigned a new random id.
The payment_source resource is also deprecated and a new active payment_source resource is created and linked to the new customer resource. Here too, the active resource adopts the id of the deprecated payment_source, which in turn is assigned a new random id.
The subscription and invoice resources remain linked to the deprecated customer resource.

subscription resourcesWhen the subscription renews, it automatically transfers to the business entity of the active customer resource. This process mirrors the transfer of the customer resource, resulting in a new active subscription resource linked to the active customer resource and the business entity acme-eu.

The list of unique identifiers of the customer resources to be transferred. Each id must belong to an active customer resource.
Note
If a customer resource was deprecated because it was moved previously, you cannot move it again. Instead, move the active version of the resource. Do this by passing the active_id of the deprecated resource.
customer resources. Returns a list of business_entity_transfer resources meeting all the conditions specified in the filter parameters below. By default, this list is sorted by created_at in descending order (latest first).
Tip
To retrieve a history of all the business entity transfers for a resource, pass the filter parameters active_resource_id[is] and resource_type[].
Filter business_entity_transfer resources based on resource_type.
Tip
Use this filter along with active_resource_id[is] to retrieve the history of all the business entity transfers for a resource.
business_entity_transfer resources based on resource_id. Filter business_entity_transfer resources based on active_resource_id.
Tip
Use this filter along with resource_type[ to retrieve the history of all the business entity transfers for a resource.