subtain-apimatic-sdk
Advanced tools
Maxio Advanced Billing (formerly Chargify API) can be integrated with many environments and programming languages via our REST API. Some of our users have contributed their API wrappers in various programming languages. Check out the API Code Overview doc for an introduction to the wrappers and available code samples.
Maxio Advanced Billing has compiled a testing guide that covers a list of important factors to consider while in the testing phase. Here's a high-level overiew of what's covered in our testing guide:
We strongly suggest reading over the testing guide, as well as the entire set of application-based documentation to aid in your discovery of the product.
We always enjoy (and appreciate) hearing about larger integrations ahead of time. If you’re planning on importing a large amount of data into Maxio via our API, we suggest sending a “heads up” to “support@chargify.com” so we can coordinate with you to ensure your import process goes smoothly.
Our API, while considered stable, is continually being improved and polished. Please feel free to contact support if you experience issues when integrating with the Maxio Advanced Billing API.
If you have any additional questions regarding our documentation please don't hesitate in reaching out.
Access to our Technical Specialist team for API support is currently limited to purchasers of our larger Maxio support plans.
But don’t worry! There are quite a few options to help you get the answers you need:
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.
JSON is the primary and recommended format for use with the Chargify API. XML is also provided as a backwards compatible option for Merchants who require it.
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>.chargify.com/<resource URI>
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 may be considered as false. However, this is not true across all cases. Please excercise good judgement here, or contact support with any questions.
For example:
null can define that there's no data available for that attributeWhen an endpoint returns a list of items, it will be paginated. Usually, 20 items will be returned by default, and you may request up to a maximum of 200 at a time. Pagination is done with query string parameters, for example: ?page=5&per_page=200
API responses from Chargify are sent with the timezone of current Chargify site.
Alternately, webhooks sent from Chargify globally utilize EST as the timezone for all content in the body of the payload.
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.
In order to prevent losing precision, we serialize decimal numbers as strings instead of as JSON numbers.
We recommend parsing these strings into their decimal equivalent using a decimal number library in your programming language (i.e. BigDecimal in Ruby) instead of relying on floating point values or arithmetic.
Fields holding amount values are given as a string representing a decimal whole currency amount.
For example, "1.23" in currency "USD" would equate to $1.23.
Not all fields will be rounded to the smallest currency denomination. Intermediate results, such as those that derive from line-level tax calculations, may hold precision up to 8 decimal places. However, the top-level totals we provide (e.g. total_amount) will be rounded to the smallest currency denomination.
It is up to API consumers to parse the string into a decimal number representation and do any rounding necessary for your application.
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 Beeceptor. You can use this to intercept your request to see exactly what is being sent.
If you are unable to connect at all, check that you are using TLS 1.2 or better.
If you see a "Could not resolve host" error, double check that the url is correct, including your subdomain. For example: mysite.chargify.com. This error means your DNS server could not find an IP address for the domain you are trying to connect to.
We consider the following changes to be backwards compatible and may make them without advance notice:
In addition, you should not depend on the order of attributes within the API response as this may change.
Chargify does not provide notifications for additions that are clearly defined as backwards compatible.
The following examples use the curl command-line tool to execute API requests.
Request
curl -u <api_key>:x -H Accept:application/json -H Content-Type:application/json https://acme.chargify.com/subscriptions.json
There are a few scenarios that may end up in causing an API request to be blocked even with correct credentials. Please note: All relevant API requests will be blocked if any of the below conditions are true. These limitations also apply to Chargify Direct.
Those scenarios are as follows:
Read more about your Chargify subscription here
The request will fail with a 422 http status code. The response will also include a message explaining the reason for the request being blocked. For example:
{
"errors" => [
[0] "Your Chargify account has been canceled. Please contact support@chargify.com to reactivate."
]
}
{
"errors" => [
[0] "Your trial has ended, please contact sales."
]
}
{
"errors" => [
[0] "Site data clearing is in progress. Please try later."
]
}
{
"errors" => [
[0] "This site has been deleted."
]
}
Please note that it is NOT possible to make API requests directly from the customer's browser or device. Doing so would expose your API key on the client side, and anyone who has that key has full access to all of your Chargify data.
Instead you will need to take care to tokenize sensitive information by using Chargify.js or a similar JavaScript library provided by your gateway, and then post the token and other information to your own server, from which you can make the API call to Chargify.
If you attempt to make a Chargify API request directly from the customer's browser, you may see an error such as:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
or
Origin 'https://example.com' is therefore not allowed access.` `The response had HTTP status code 404.
This is an error message indicating that Cross-Origin Resource Sharing (CORS) is not enabled on the Chargify server.
This section describes the API for the new, Relationship Invoicing style of invoices introduced in January 2018.
If you are an existing customer from prior to January 2018 or have not otherwise explicitly opted into this new style of invoices, you are probably looking for the legacy "Invoices" section that describes invoice-billing legacy-style invoices.
These new invoices provide a single representation of all of your Chargify billing, whether you collect automatically or via remittance.
In order to prevent losing precision, we serialize decimal numbers as strings instead of as JSON numbers.
We recommend parsing these strings into their decimal equivalent using a decimal number library in your programming language (i.e. BigDecimal in Ruby) instead of relying on floating point values or arithmetic.
Fields holding amount values are given as a string representing a decimal whole currency amount.
For example, "1.23" in currency "USD" would equate to $1.23.
Not all fields will be rounded to the smallest currency denomination. Intermediate results, such as those that derive from line-level tax calculations, may hold precision up to 8 decimal places. However, the top-level totals we provide (e.g. total_amount) will be rounded to the smallest currency denomination.
It is up to API consumers to parse the string into a decimal number representation and do any rounding necessary for your application.
If your site is using relationship invoicing, you may only use the methods described in this section for working with invoices.
If your site is not using relationship invoicing, please use the legacy invoice methods:
Install the gem from the command line:
gem install subtain-apimatic-sdk -v 11.1.11
Or add the gem to your Gemfile and run bundle:
gem 'subtain-apimatic-sdk', '11.1.11'
For additional gem details, see the RubyGems page for the subtain-apimatic-sdk gem.
Note: Documentation for the client can be found here.
The following parameters are configurable for the API Client:
| Parameter | Type | Description |
|---|---|---|
subdomain | String | The subdomain for your Chargify site. Default: 'subdomain' |
domain | String | The Chargify server domain. Default: 'chargify.com' |
environment | Environment | The API environment. Default: Environment.PRODUCTION |
connection | Faraday::Connection | The Faraday connection object passed by the SDK user for making requests |
adapter | Faraday::Adapter | The Faraday adapter object passed by the SDK user for performing http requests |
timeout | Float | The value to use for connection timeout. Default: 30 |
max_retries | Integer | The number of times to retry an endpoint call if it fails. Default: 0 |
retry_interval | Float | Pause in seconds between retries. Default: 1 |
backoff_factor | Float | The amount to multiply each successive retry's interval amount by in order to provide backoff. Default: 2 |
retry_statuses | Array | A list of HTTP statuses to retry. Default: [408, 413, 429, 500, 502, 503, 504, 521, 522, 524] |
retry_methods | Array | A list of HTTP methods to retry. Default: %i[get put] |
http_callback | HttpCallBack | The Http CallBack allows defining callables for pre and post API calls. |
basic_auth_credentials | BasicAuthCredentials | The credential object for Basic Authentication |
The API client can be initialized as follows:
client = AdvancedBilling::Client.new(
basic_auth_credentials: BasicAuthCredentials.new(
username: 'BasicAuthUserName',
password: 'BasicAuthPassword'
),
environment: Environment::PRODUCTION,
subdomain: 'subdomain',
domain: 'chargify.com'
)
The SDK can be configured to use a different environment for making API calls. Available environments are:
| Name | Description |
|---|---|
| production | Default Production server |
| environment2 | Production server |
This API uses the following authentication schemes.
FAQs
Unknown package
We found that subtain-apimatic-sdk demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.