Skip to main content

We are receiving error messages with the API, but the status returns as 200. For example, when we hit our complexity limit we get a status 200 with a response payload of


{'errors': [{'message': 'Query has complexity of 30001, which exceeds max complexity of 9473'}], 'account_id': 4440630}

Another example includes using the “change_multiple_column_values” mutation which reports an error when a column value isn’t properly formatted for its column type. This is an example of the response payload with a status 200:


{'error_code': 'ColumnValueException', 'status_code': 200, 'error_message': 'invalid value, 

please check our API documentation for the correct data structure for this 

column. https://monday.com/developers/v2#column-values-section', 'error_data': 

{'column_value': '2095 - Meat Product Manufacturing', 'column_type': 'NumericColumn'}}

Generally speaking, we would expect errors to return a 4XX or a 5XX status code. Receiving errors as a status 200 is misleading and it appears that the key for finding an error is inconsistent. IE, the complexity limit returns its errors within the “errors” key, but the ColumnValueException error has keys of “error_code”, “error_message”, and “error_data”. Would it be possible to make these errors return some non-200 status code instead to make them more identifiable?

Hey @dturcanbbi – thanks for posting!


Sounds like you are bringing up two points here:




  1. Error Status Codes: If there are errors in your GraphQL query, the API will still return a 200 status code. This is a decision we made to ensure our API conforms with the GraphQL specification.


    The specification defines GraphQL as an application layer, but the status code reflects the status of a transport layer.


    For example, status of 400 or 500 means: “Something in the structure of your request is preventing our API from parsing your request at all”.


    While a 200 status on the ColumnValueException means: “The request was parsed successfully, but there was an issue with it. Your column values don’t look correct.”




  2. Inconsistent error keys: Some exceptions return an array of errors in the “errors” key, while other exceiptions return an object that contains “error_code”, “error_message”, etc. This is definitely something that we can look at changing to make it more consistent.




Does that summarize the issue at hand? Let me know and I’ll go ahead and submit #2 to our dev team for review.

Thank you for the reply dipro! Your summarizations are accurate. Handling #2 would be a great step in the right direction. Once that consistent key is agreed upon, it would be helpful to be noted in the API documentation as well.

@dturcanbbi – will do! I’ll add this feedback to our documentation backlog too.


Hi 🙂


I would really appreciate you make it more consistent and also more specific.


I have a system that needs to retry the action when the query is failing because of API Limit since the request itself is valid but the server don’t want to execute it for now, but should reject the action when the query is failing for any other reason.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Terms & ConditionsCookie settings