Check out our new & improved API documentation here, complete with request examples, response examples and much more. 

We will return HTTP 200 status code for all successful GET requests. 204 will be given for successful updating POST/PATCH or DELETE requests when there will be no content to return. POST create operations which will return 201 and the new resource url will be available in the Location header.

Errors using the API will be returned as 4xx errors such as 400 (Bad request, perhaps indicating missing parameters) and 404 (Not found, indicating the API resource does not exist in the location asked for)

Errors on the API's own server will be returned with 5xx error codes.

We will also try to return JSON encoded error packets to tell the applications what has happened such as:

{
    "errors": [{
        "status": 400,
        "message": "Missing \”product_id\” parameter."
    }]
}

However, user errors such as “the verification of a code failed” will return a header 200 status but will return a status=="invalid" and info in the errors array for the reason as to why it failed. Such as, the code is invalid, or out of date.

All errors should also provide links back to a location where developers can find more details and a community discussion to help solve any problems they are having using the api.

We are aware some clients cannot use some of the http status codes because it causes issues for them, so we provide a URL param of suppress_response_codes to override them and just return a status code of 200. With this you'll have to check the errors array to make sure the request was successful. (Its the same param Twitter use and its long, so its very obvious what it does to avoid misuse & issues)

e.g. http://store.com/api/v1/products.json?suppress_response_codes=true