...
HTTP status code | Description |
200 | SUCCESS The API call was successful and includes a json formatted result according to the API documentation. |
204 | SUCCESS The API call was successful. The method does not return any results. |
400 | FAILED The API call failed. The http call returns a json which describes the error. The json document has these properties: { "" type": Error category. You usually do not need to read this.message": A user friendly and (generally) localized error message. Designed to be readable by end users. It is recommended to show these errors to the end user (if applicable). "id": Some errors include an error identifier. Where used, ids are described with the API methods:
"inner": In some cases includes a more technical error description. You would not show this to the end users. "For example the ID may help your code to decide how to react to errors. See Error IDs for a complete list. "info": Optional additional description for the eyes of the developer. This should never be shown to the end user. failed": Always set to " falsetrue". }
What error do I show to the end user? You can safely display the "message" content to the end user. It will be localized in the language you specified when connecting.
How to I adapt the control flow of my software? The "id" value may give you an indication of what failed and may be used to decide what to do in your program. See: Error IDs. Use when you feel you need it.
|
Other codes | FAILED There may be other http error codes returned. Other error codes that do may or may not return a json JSON object. These are low level errors likely due to network problems or programming errors. Problems originating inside the Wordbee API will return a JSON (see example further down). Requests failing prior to the web server configuration and not the Beebox API itself. For example, a 404 error points to an inexistent API method. |
...
reaching the API will not return a JSON. If there is a JSON it is for your information only and must never be shown to the end user (or only as a supplement).
What error do I show to the end user? You need to show your own generic error message such as "Oups, this operation failed". You may want to use the HTTP status code to decide what to display, for example:
For a full list of error codes see: HTTP status codes (Wikipedia)
|
EXAMPLES
Status 400 error
This is the JSON result if you are not connected. had specified an invalid domain value during connection. The HTTP status code is 404:400.
| Code Block |
|---|
{
"typeid":"Api errorLOGIN_FAILED",
"idmessage":"LOGGEDOUTLogin failed.",
"message "info":"Not authorised", "Invalid API domain: InstaTra."
"failed":true
} |
Low level error - Not network related
If you call wrong API methods or with wrongly named or missing parameters, then you get a status code 404 and a result which is formatted differently from what is described further up:
...
Such errors point to development errors.
WINDOWS EVENT LOG
Most errors are written to the Windows event log. You will find full error details there.
We recommend to systematically check the Windows Event Viewer tool for debugging and error analysis.Low level error - Network related
Returns an HTTP status code but typically does not include any other details. For example, a firewall will not describe the exact issue at hand.
If the error is generated by a proxy server then additional technical information may be returned.