Authentication
Every HTTP request coming to Infogr.am REST API service is being verified for API user’s authenticity. To accomplish this, two HTTP request parameters are important: the api_key and the api_sig: the former identifies the API account (and hence the user) itself and the latter contains so-called “request signature” which is computed by the caller using the API account’s secret key before sending the request.
The subject of this request authentication process is every HTTP request to the Infogr.am API service (i.e., every requested URL starting with https://infogr.am/service/v1/) disregarding the HTTP method (e.g. GET, POST etc.).
Request signing
Each request to the Infogr.am REST API service must be signed. Also, each request must have the api_key parameter (in the query string or request body) which is equal to your account’s API key. Invalid or absence of both request signature and the api_key parameter will lead to HTTP response with code 400 “Bad Request”.
REST API HTTP response
Each successful response comes with status code 200 “OK” or 201 “Created”. There is a possiblity that this may change in the future, however it will remain that a successful response can be identified with a status code number between 200 and 299.
Successful response body depending on the request type can contain data which can be either plain text or JSON structure if response header indicates appropriate content type (application/json).
Each non-successful response comes either with status code between 400 and 499 or between 500 and 599. Usually a more concrete description of the problem can be found in the response body.
Status codes between 400 and 499 indicate that there is something wrong with the request itself - it might be either incorrect (400 “Bad Request”), it might reference a non-existing resource (404 “Not Found”) or user on which behalf API is accessed to might have insufficient privileges to perform certain operation (403 “Forbidden”)
Status codes between 500 and 599 indicate some problem with the API service. Most probably you should retry the request after some time or, if nothing changes, contact Infogr.am support.
ApiService->checkForResponse()andApiService->checkForValidRequest()ApiService->checkSettings()Return detailed infos ( 1) when API response isNULL2) when response is not NULL butresponse->isOK()is falseAuthentication
Every HTTP request coming to Infogr.am REST API service is being verified for API user’s authenticity. To accomplish this, two HTTP request parameters are important: the api_key and the api_sig: the former identifies the API account (and hence the user) itself and the latter contains so-called “request signature” which is computed by the caller using the API account’s secret key before sending the request.
The subject of this request authentication process is every HTTP request to the Infogr.am API service (i.e., every requested URL starting with https://infogr.am/service/v1/) disregarding the HTTP method (e.g. GET, POST etc.).
Request signing
Each request to the Infogr.am REST API service must be signed. Also, each request must have the api_key parameter (in the query string or request body) which is equal to your account’s API key. Invalid or absence of both request signature and the api_key parameter will lead to HTTP response with code 400 “Bad Request”.
REST API HTTP response
Each successful response comes with status code 200 “OK” or 201 “Created”. There is a possiblity that this may change in the future, however it will remain that a successful response can be identified with a status code number between 200 and 299.
Successful response body depending on the request type can contain data which can be either plain text or JSON structure if response header indicates appropriate content type (application/json).
Each non-successful response comes either with status code between 400 and 499 or between 500 and 599. Usually a more concrete description of the problem can be found in the response body.
Status codes between 400 and 499 indicate that there is something wrong with the request itself - it might be either incorrect (400 “Bad Request”), it might reference a non-existing resource (404 “Not Found”) or user on which behalf API is accessed to might have insufficient privileges to perform certain operation (403 “Forbidden”)
Status codes between 500 and 599 indicate some problem with the API service. Most probably you should retry the request after some time or, if nothing changes, contact Infogr.am support.