6px.io API Documentation
This page will help you get started with 6px. You'll be up and running in a jiffy!
The 6px API is organized around REST and designed to have predictable, resource-oriented URLs and use HTTP response codes to indicate API errors. All responses from the API, including errors, will return JSON (though if you're using API bindings, we will convert the response to the appropriate language-specific object).
Our API also uses built-in HTTP features, like HTTP authentication and HTTP verbs, which can be understood by off-the-shelf HTTP clients, so you don't need to install any additional software to run our API.
We also support cross-origin resource sharing to allow you to interact securely with our API from a client-side web application (though you should remember that you should never expose your secret API key in any public website's client-side code).
We designed the 6px API in a very RESTful way, so that your consumption of it is simple and straightforward. From Wikipedia:
REST's proponents argue that the Web's scalability and growth are a direct result of a few key design principles:
- Application state and functionality are divided into resources
- Every resource is uniquely addressable using a universal syntax for use in hypermedia links
- All resources share a uniform interface for the transfer of state between client and resource, consisting of a constrained set of well-defined operations and a constrained set of content types, optionally supporting code on demand.
- A protocol which is: stateless, cacheable, and layered.
REST's client/server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries-proxies, gateways, and firewalls-to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching.
REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.
All URLs referenced in the documentation have the following base:
Alternatively, you can access the API using Basic Authentication. To do so, provide your API Key as the username and your API Secret as the password.
6px uses conventional HTTP response codes to indicate success or failure of an API request. In general, codes in the 2xx range indicate success, codes in the 4xx range indicate an error that resulted from the provided information (e.g. a required parameter was missing, etc.), and codes in the 5xx range indicate an error with 6px's servers.
Not all errors map cleanly onto HTTP response codes, however. When a request is valid but does not complete successfully (e.g. a card is declined), we return a 402 error code.