Answers.Body: <p>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).</p>
  
  <p>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.</p>
  
  <p>That said, this question really calls for no more than personal opinions so should probably be closed.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-18T16:07:41.560Z
Answers.Text: I'm not sure I agree that they're typically indicative of 'plumbing' issues. For example the [OneDrive api](https://dev.onedrive.com/misc/errors.htm) uses a whole range of 4xx and 5xx return codes to indicate various errors helpfully. But I accept the personal opinions point.
Answers.UserDisplayName: Adam Hillier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-12T19:09:53.597Z
Answers.LastActivityDate: 2016-07-12T19:09:53.597Z
Answers.UserDisplayName: DaveD
Body: <p>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.</p>
  
  <p>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).</p>
  
Tags: <api>
Title: Should the API return code always be 200?
ThreadText: # Should the API return code always be 200?
  
  (Asked by: username_0 on 2016-07-12)
  
  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).
  
  **Tags:** api
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-07-12. Score: 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.
  
  > **Comments:**
  > **username_0**: I'm not sure I agree that they're typically indicative of 'plumbing' issues. For example the [OneDrive api](https://dev.onedrive.com/misc/errors.htm) uses a whole range of 4xx and 5xx return codes to indicate various errors helpfully. But I accept the personal opinions point.  
  
  ---
  
  