Example:

// success
{
    "status": "success",
    "data": {
        "id": 123,
        "name": "John Doe",
        "email": "john@example.com"
    }
}

// error
{
    "status": "error",
    "message": "User not found",
    "code": "NOT_FOUND"

}

Why status field when we can rely on HTTP status codes?

1. Unified handling of API response

   A 404 Not Found or 500 Internal Server Error tells us the request failed. However, relying solely on these codes can create unnecessary complexity in your client-side logic. Without a "status" field, clients need to parse out the actual error details from various fields, which can be messy and prone to errors.

    if (response.status === 'success') {
      handleSuccess(response.data);
    } else {
      handleError(response.message);
    }
   

2. Handling complex application logic

   1. Multi status needs

      Sometimes a single HTTP status code can’t capture the complexity of an API operation. For instance, a batch process might successfully process some records while failing others. Returning a simple 200 OK wouldn’t convey the partial success.

       {
         "status": "partial_success",
         "successful": 3,
         "failed": 2
       }
      

   2. Asynchronous operations

      In APIs with asynchronous processing, an initial request may return 202 Accepted while the operation continues in the background. Relying solely on HTTP codes doesn’t communicate the operation’s progress.

       {
         "status": "in_progress",
         "estimated_time": "5 minutes"
       }
      

3. Ensuring Cross-platform Consistency

   Not all communication protocols handle HTTP semantics uniformly. For instance:

   • WebSockets don’t use traditional HTTP status codes.

   • Non-HTTP services like message queues may require their own success/error indicators.

Conclusion

Using a status field alongside HTTP status codes simplifies API response handling, improves error communication, and prepares APIs for more complex scenarios like batch processing and asynchronous operations. By adopting this pattern, you build APIs that are more predictable, developer-friendly, and future-proof.