The Chargify API allows you to interact with our system programmatically from your own application. Using the API you interact with Resources such as:
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 SSL (https), as described in API Authentication
The URL for API requests includes the subdomain of the Site you are working with:
The available resources are listed on the API Resources page.
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
GETs for individual statements & invoices may also be requested as PDF using
application/pdf or appending
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.
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
.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/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.
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.