I see an issue with the API where I receive a status code of 200 for requests that actually fail, instead of the expected 400 status error code. Even if the request is not being processed as intended due to an error, the response still indicates successful execution with a status code of 200. However, the response body contains error messages indicating that something went wrong.
This behavior is problematic for my application. I use error handling mechanisms, which rely on the HTTP status code to determine the outcome of a request. When a request fails, I expect to receive an appropriate error code (e.g. 400) that accurately reflects the failure, allowing my system to respond accordingly.
It’s important to mention that at the moment, I see this happen only with status 400. If there are server issues (500) or rate limit issues (429), I do get the right status code. But not for 400; instead, I see 200 and error messages.
Could you please assist in resolving this? I am looking for guidance on how to ensure that error responses correctly reflect the failure through appropriate HTTP status codes.
This behavior of returning a 200 is specification compliant for GraphQL. If the error is a server issue, or rate limit (more than 5000 requests per minute - not the API Complexity Limit), those are upstream from the GraphQL resolvers and will return HTTP status codes.
GraphQL returns its errors as values in the response body with a 200 status code. This is not a bug, it is per the GraphQL specification. That said monday’s error responses within that body do not follow the specification, but they are documented: Error codes
GraphQL specification only provides for an errors object in the response, the error_code and error_messages that monday ALSO may use are not spec complaint.
You need to check your response for the presence of a data object, if there is no data object then there is an error. As far as I know monday never returns a data object when there is an error (though this is not a GraphQL requirement). Monday also returns an extensions object which you should log, as it contains deprecation notices if your call contains a deprecated component.
IF monday.com did not use the error_code and error_message fields and instead adhered to the GraphQL spec of only returning errors in an errors object, you would be able to automate this using graphql-request for javascript (for example) which is a standards compliant client. It would throw exceptions for the errors. In the meantime you can wrap the monday client in your own code, check for data and if not present, parse out the rest of the errors and throw an except on error with information from the error. (Or get fancy and handle the different errors as different exception types).