API Overview

• Adding new API resources.
• Adding new attributes to existing API responses.
• Changing the order of attributes in existing API responses.
• Adding new API methods for a resource.
• Adding new 'optional' input params to existing API methods.
• Adding new attributes to existing API responses.
• Making an input param 'required' in API methods (very rare).
• Adding new event types.

# creates a subscription with customer information and billing details.
curl  https://{site}.chargebee.com/api/v1/subscriptions \
     -u {site_api_key}:\
     -d plan_id="no_trial" \
     -d customer[first_name]="John" \
     -d customer[last_name]="Doe" \
     -d customer[email]="john@user.com" \
     -d billing_address[first_name]="John" \
     -d billing_address[last_name]="Doe" \
     -d billing_address[line1]="PO Box 9999" \
     -d billing_address[city]="Walnut" \
     -d billing_address[state]="California" \
     -d billing_address[zip]="91789" \
     -d billing_address[country]="US" \
     -d customer[auto_collection]="off"

# creates a subscription with customer information and billing details.
curl  https://{site}.chargebee.com/api/v1/subscriptions \
     -u {site_api_key}:\
     -d plan_id="no_trial" \
     -d customer[first_name]="John" \
     -d customer[last_name]="Doe" \
     -d customer[email]="john@user.com" \
     -d billing_address[first_name]="John" \
     -d billing_address[last_name]="Doe" \
     -d billing_address[line1]="PO Box 9999" \
     -d billing_address[city]="Walnut" \
     -d billing_address[state]="California" \
     -d billing_address[zip]="91789" \
     -d billing_address[country]="US" \
     -d customer[auto_collection]="off"

Sample Response [ JSON ]

Some of the resources have a corresponding details page in the Chargebee's admin console. In some cases you might want to construct the admin console url for easy access from your app (or from exported xls sheets). As the admin console urls are based on internal ids you need to construct the url in the below given format.

Here is an example of a constructed url for a subscription with id 123xyz

• Accessing the constructed url in a browser will redirect it to the details page.
• The login page will be shown if the user has not yet logged-in into Chargebee's admin console.
• Not all resources will have the corresponding details page. To know if it is supported, please look at the cURL documentation under the retrieve operation for that resource.
• Do not store the redirected internal id based url as it may change.

Chargebee supports billing in 100+ currencies. APIv1

Take a look at the list of supported currencies here.

Handling Currency Units

While specifying amount in any currency, you need to provide the amount in the smallest unit of that currency. For example, to specify an amount of $1.50, you would set amount=150 (i.e. 150 cents).

For zero decimal currencies (currencies that do not have decimal units), however, you need to provide the amount in the regular denomination. For example, to specify an amount of ¥15, you would set amount=15 (i.e. 15 yens).

Chargebee currently supports below zero-decimal currencies:

• KRW - South Korean Won
• JPY - Japanese Yen
• XAF - Central African CFA Franc
• XOF - West African CFA Franc

Multicurrency Support

With our Multicurrency support, you will be able to process transactions in additional currencies apart from your site's Base currency.

Once Multicurrency support is enabled, the API methods listed below will throw an error as currency_code is required for these methods to work and the same is not supported in the V1 version. So upgrade to our latest version (V2) to be able to pass currency_code input parameter to these methods in Multicurrency mode.

• Customer related methods
• Add account credits to a customer
• Deduct account credits from a customer
• Set account credits for a customer
• Invoice related methods
• Create an invoice
• Create invoice for charge
• Product Configuration related methods
• Create a plan
• Update a plan
• Create an addon
• Update an addon
• Create a coupon

What are business entities?

A Chargebee site can be divided into multiple business entities, each with its own configuration and data. By default, a site has only one business entity. Here are some use cases for which you can create multiple:

• You may be running your business under different regional units with different "invoice-from" addresses. This is usually done to manage taxation and bookkeeping. In such a case, you may create a business entity for each business unit.
• You may have multiple brands within your business, such as those acquired via mergers and acquisitions. You may create a business entity for each brand.

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.

Specifying the business entity

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.

Terminology

This section defines some useful terms for describing how business entities work.

Linked business entity

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.

Default business entity

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. At first, it is the same as the first business entity of the site and can be changed once more business entities are created. Contact Support to change the default business entity.

Context of an operation

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.

Target resource

While creating an API resource other than a customer, you specify a target resource under which it should be created. For example:

• While creating an 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.
• While creating a subscription, the target resource of a subscription resource is always a customer resource.
• While creating a quote resource of type change_subscription, the target resource is a subscription resource.

Chargebee supports configuring multiple gateway accounts for a gateway type (eg: you can configure multiple Authorize.net accounts to process multiple currencies).

If you have multiple gateway accounts for a gateway type, the API methods listed below will throw an error as gateway_account_id is required for these methods to work and the same is not supported in the V1 version. So upgrade to our latest version (V2) to be able to pass gateway_account_id input parameter to these methods.

• Customer related methods
• Create a customer
• Update payment method for a customer
• Card related methods
• Update card for a customer
• Switch gateway
• Subscription related methods
• Create a subscription
• Update a subscription
• Hosted page related methods
• Checkout new subscription
• Checkout existing subscription
• Update payment method

Chargebee restricts API requests when you exceed the limits entitled for your plan. The limiting mechanism is employed considering two criteria:

• Requests per minute - Number of requests in the past 60 seconds.
• Concurrent requests - Number of requests at an instance of time.

• Test sites: ~750 API calls per every 5 minutes
• Live sites: ~150 API calls per site per minute

When the upper limit is breached on either of the above criteria, an HTTP 429 error response is returned for subsequent requests. As a result, no more requests are served until the limit resets (in approximately a minute). For more details about error 429, refer to api_request_limit_exceeded in Error Codes List.

Please note that a cooling period is set for both test and live sites:

• For test sites: five minutes from the time error 429 is thrown
• For live sites: one minute from the time error 429 is thrown

If you need a temporary rate limit increase, contact Chargebee Support to have it increased. Furthermore, if you exceed your limit frequently, you should consider upgrading to a higher plan (see table below) in order to accomodate the increase of your API request volume.

Listed below are the API rate limits for each Chargebee plan:

HTTP status codes are used to indicate success or failure of an API call. The body of the response contains the details of the error in JSON format.

Sample error response:

Given below is a sample error that is returned for the Create a subscription API call when the plan_id is invalid. The returned HTTP status code is 404.

Http Status Codes

The standard http status codes used are

• 2XX The response code in this range implies the API call has succeeded.
• 3XX This range is not used currently.
• 4XX response codes indicate failure due to wrong input (i.e, client) side. As the usable list of http codes in the 4xx range is limited we predominantly use the 400 ( BAD REQUEST ) error code for client-side errors.
• 5XX response codes indicate API request was valid but failed due to issues on the Chargebee server.

Error Attributes

Note: There may be additional deprecated attributes (like error_code) which are present to support older versions of the libraries.

Error handling recommendations

API calls fail at the first error encountered by Chargebee while validating them. To enhance user experience, we recommend that you validate an API call thoroughly to avoid multiple failed attempts from your users, each time for a different error.

There are cases where you have to depend on Chargebee's validation for handling errors like coupon code validation or VAT validations. In such cases, check the specific param and api_error_code combination to show a proper error message to your users.

Handling API Throttling

If you receive an HTTP 429 Too Many Requests error response to an API call, it means that the API requests for your Chargebee site have exceeded acceptable limits. Chargebee may also send a Retry-After header indicating the time duration to wait before sending a new request. Follow these best practices:

• If you see the Retry-After header, wait for the number of seconds indicated before retrying.
• Use an exponential backoff algorithm when making further requests.
• To prevent all your request threads/processes from retrying simultaneously (thundering herd problem), add some randomized jitter to the backoff algorithm to spread the requests out.

See Also: API Rate Limits.

The following are the list of codes grouped based on type.

Note: 'New' codes might get added (though additions are very rare). If you are handling for specific codes also ensure that there is a default block for handling unknown(/new) error codes.

These errors may occur when trying to store the payment method details(such as card, paypal, ACH etc) or when trying to collect a payment. These errors should be handled and appropriate message should be shown to the user. The type attribute in the error response is sent as payment.

The following errors are caused due to invalid request. In most cases the errors should occur only during the development phase. The type attribute in the error response is sent as invalid_request.

These errors are returned when the request was valid but the requested operation could not be completed. These errors should occur very rarely. You generally need not handle them specifically other than showing a generic error message to your users. The type attribute in the error response is sent as operation_failed.

Most of these errors occur due to improper API environment setup in your server or changes to the site's configuration. The type attribute is not sent in the error response.

Providing user details

Passing user details like IP address, email address and Device information from your website to Chargebee is always useful. IP address information is routed to the payment gateway (where it will be validated against active fraud detection filters), used for EU tax validation, referral integration and event reports. Email addresses and Device information, even more ubiquitous, are used for identification. Chargebee supports http headers to send user details.

Use the following headers to send user details across:

• For the IP address of the customer where the request originated - chargebee-request-origin-ip; where an example is 192.168.1.2.
• For details of the customer - chargebee-request-origin-user; where an example is user@example.com.
• For the device from which the customer has made the request - chargebee-request-origin-device; where an example is Android.

 curl  https://mysite.chargebee.com/api/v1/customers \
     -H chargebee-request-origin-ip:192.168.1.2\
     -H chargebee-request-origin-user:user@example.com\
     -H chargebee-request-origin-device:Android\
     -u myapikey: \
     -d customer[email]="john@user.com" \

Disabling webhooks and emails

Sometimes you would want to disable emails or webhooks for the events that are generated for a particular api call. Typically you would need this when you are migrating customers from your system to Chargebee via api. One option would be to disable all the emails(/webhooks) for all events during the import process. But then you would still want to send emails for new customers who are signing up.
Chargebee supports custom http headers on each api request that allow you to control the actions that are triggered on the events generated by that particular api call.

• To skip all actions to be done on the events pass the header chargebee-event-actions with value all-disabled
• To skip only emails pass the header chargebee-event-email with value all-disabled
• Similarly to skip only webhooks pass chargebee-event-webhook with value all-disabled

        curl  https://mysite.chargebee.com/api/v1/customers \
     -H chargebee-event-actions:all-disabled \
     -u myapikey: \
     -d customer[email]="john@user.com" \
    

Chargebee sends webhook events from specific IP addresses. If you receive webhooks, you may need to configure your integration to ensure that you only receive such notifications from the IP addresses listed below.

Notifications for Updates
Any changes to our IP addresses are notified via the API Changelog. Alternatively, if you use a Google account, you can turn on notifications for the Google Sheets version of these lists.

United States (US) Region

Webhooks for Chargebee sites hosted in the US region originate from the following IP addresses:

View the above list in Google Sheets

European Union (EU) Region

Webhooks for Chargebee sites hosted in the EU region originate from the following IP addresses:

View the above list in Google Sheets

Chargebee gives you the option of creating custom fields to track additional information about Customers and their Subscriptions. You can create custom fields for customers, subscriptions, plans, and addons. Once the custom fields are created, they can be added to the hosted checkout pages and invoices. They can be accessed through the web interface and API. More on Custom Fields here.

Sample Request

curl https://{site}.chargebee.com/api/v1/subscriptions \
-u {site_api_key}: \
-d plan_id="basic" \
-d "cf_notes"="sample" \
-d "customer[cf_gender]"="sample"

If you would want to store additional/custom data at a resource's level, you can make use of Meta Data.

For example, if you're a data service provider and would want to store certain features of a particular plan such as "Usage Limit", "Speed within limit", etc., you can have it stored in the Meta data of the Plan.

Meta Data can be passed during the Add/Update operations, for the following resources:

• Subscriptions
• Customers
• Plans
• Addons
• Coupons

Meta Data can only be stored in the JSON format. You can also use nested JSON objects.

Considering the same example as above, if you'd want to store the additional features of a particular data plan here's how the JSON would look:

Tutorials and use case guides for developers can be found here.