#KickFolio API
Kickfolio API
Our API allows you to create and manage your Apps, including uploading new Versions, removing Versions, and commenting on Versions.
All responses are in JSON format, and the URL structure generally tries to follow RFC-2616.
Authentication
All requests are authenticated using your authentication token, which is found on your account page when logged into the Kickfolio dashboard.
There are two ways to authenticate:
- Supplying an
Authorizationheader (preferred) - Supplying the
auth_tokenparameter
Authenticating with headers
Header authentication follows the typical HTTP Authorization scheme of providing a BASE64 encoded hash to your authentication credentials. In this case the credentials are simply your authentication_token.
To generate the correct header simply apply a Base64 strict encoding (no linefeeds) to your authentication_token and send it as HTTP Basic auth: Authorization: Basic MY_BASE64_ENCODED_TOKEN. If your client library insists on supplying a password for sending basic auth, you can use X, which will be ignored on our end.
Ruby example:
encoded_token = Base64.strict_encode64(authentication_token) request.header('Authorization', "Basic #{encoded_token}"
Parameter based authentication
The second option for authentication is supplying the auth_token parameter on the end of your query.
Here's an example:
curl http://kickfolio.com/api/apps?auth_token=MY_RAW_AUTH_TOKENVersioning
All API requests are subject to versioning, where the current version is always the latest version. It is strongly advised that you specify a specific version when requesting API resources. This is done by supplying an HTTP Accept e.g.
curl -H 'Accept: application/vnd.kickfolio.v1' http://kickfolio.com/api/appsThe versioning format is application/vnd.kickfolio.v1 where v1 is the version idenifier. At the time of writing the only version available is v1, however v2 is planned.
Errors
If you incorrectly access a resource the API will respond with a HTTP status code in the 4xx space or 5xx space depending on the cause. The body of the response will contain a JSON formatted error message based on the following schema:
{
"message": "STRING - A human readable exmplanation of the problem",
"code": "STRING - a unique string identifying the problem e.g. record_invalid",
"errors": [ // Optional - only on record_invalid
{
"field" : "The property which was invalid",
"resource" : "The name of the invalid resource",
"message" : "The reason the field is invalid"
}
]
}