HTTP status codes

Because infrastructure servers may intercept HTTP requests and directly return responses, a web application must not assume the response body always includes a JSON document containing the "errorCode" and "errorMessage" properties. A response may contain no response body, some other type of response body, or a proper FairCom response.

Infrastructure servers may run between your application and the FairCom server, such as reverse proxies, load balancers, API gateways, Cloudflare servers, and so forth. An infrastructure server may intercept a require and directly return a response with an HTTP status code from 401 to 504. When the response does not contain a JSON document with the "errorCode" and "errorMessage" properties, it indicates a non-FairCom server returned it.

An application must handle three categories of errors based on the HTTP status code:

• 200 OK contains a JSON action success response.
• 400 Bad Request contains a JSON action failure response.
• The remaining HTTP status codes are auth and communication failures.

Prior to V26.10, the FairCom server returned the HTTP status code of 200 OK in all responses.

As of V26.10, it returns the following HTTP status codes required by the HTTP specification:

• 200 OK
• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 500 Internal Server Error
• 503 Service Unavailable

This change may affect web applications that use the FairCom JSON action API.

The HTTP status codes 200, 400, 401, 403, 500, and 503 returned from the FairCom server always include the standard JSON action response, which includes the "errorCode" and "errorMessage" properties. When these two properties are present, the application knows the FairCom server has returned the response. If an application receives other status codes or the body does not include a proper FairCom API response, another server returned the HTTP error.