The Civicrm API seems to always return 200 (aka 'Success') even when there is an error (in the parameters of the request, or otherwise). To indicate an error, it instead sets the 'is_error' flag to '1' in the response.

This is fine, but is there a reason why it wouldn't set a more appropriate error code depending on the case (i.e. a 400 'Bad Request' code for malformed requests)? For example, when using a javascript http client and making an ajax API request it would allow use of default error handlers (function to call on success, function to call on fail).

1 Answer 1


HTTP return codes are typically indicative of "plumbing" issues between the client through the web server. A malformed API call is more indicative of an underlying data issue so doesn't really fit the same scheme (IMHO).

Further, I think that error handling for plumbing issues (ala "Website not available") probably needs to be different than that for API errors. I know my coding would always handle things differently.

That said, this question really calls for no more than personal opinions so should probably be closed.

  • I'm not sure I agree that they're typically indicative of 'plumbing' issues. For example the OneDrive api uses a whole range of 4xx and 5xx return codes to indicate various errors helpfully. But I accept the personal opinions point. Jul 18, 2016 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.