This documentation site is deprecated. The latest up-to-date API reference is available at
This site will remain available for historical reference until June 1, 2017

API Introduction

The Chargify API allows you to interact with our system programmatically from your own application. Using the API you interact with Resources such as:

  • Products
  • Subscriptions
  • Customers

The API attempts to conform to the RESTful design principles. You interact with the resources exposed via the API by accessing resource collection and element URIs using the HTTP verbs (GET, POST, PUT, and DELETE). Chargify accepts and returns both JSON and XML data via the API.

You’ll likely need access to a web developer or programmer (if you’re not one) to get the most use out of the API.


Authentication is implemented as HTTP Basic Authentication over TLS >= 1.2 (HTTPS), as described in API Authentication


The URL for API requests includes the subdomain of the Site you are working with:

https://<subdomain><resource URI>


The available resources are listed on the API Resources page.

Response Data

Response data is sent as either XML or JSON, depending on the type of data requested (HTTP Content-Type header) or the type specified as being accepted (HTTP Accept header).

GETs for individual statements & invoices may also be requested as PDF using application/pdf or appending .pdf to the resource URI.

Response codes are sent via the normal HTTP Response Code, and are documented separately for each resource.

For boolean fields, please note that a value of null should be considered as false.

Request Data

POST and PUT request data may be formatted as either XML (application/xml) or JSON (application/json). For best results, you should set your HTTP Content-Type request header accordingly, although you may also specify your format by appending .xml or .json extensions on to the resource URI.

Note that Chargify does not accept PUT or POST data sent as query params or form encoded data – data must be sent as either XML or JSON. If you fail to set your Content-Type to either application/xml or application/json, your request may fail due to triggering of forgery protection mechanisms.


If you’re having difficulty executing a request via our API, try the simplest thing and attempt your request via the curl command-line tool, as shown in the below example. Add the --verbose flag to your request to receive even more debugging information.

Another handy tool is RequestBin You could create a RequestBin and send your request to them instead of us to see visually what it is you’re sending, if you’re not sure.

If you are unable to connect at all, check that you are using TLS 1.2 or better, and review the information in API Authentication Troubleshooting.

Backwards Compatibility

We consider the following changes to be backwards compatible and may make them without advance notice:

  • Adding new API endpoints, or adding new attributes to existing endpoints
  • Adding new optional parameters to existing API endpoints
  • Changing the type or length of any of the ID attributes

For example, most IDs are currently integers, but you should not assume that this will always be the case.

In addition, you should not depend on the order of attributes within the API response as this may change.


The following examples use the curl command-line tool to exectute API requests.

Subscription listing