How to Return 400 Instead of 500 With REST API HTTP Status Codes

Why a missing field should be a 400, not a 500

REST API HTTP status codes split cleanly by their first digit. 4xx means the client sent something wrong; 5xx means the server broke. A request that omits a required field is squarely a client error - it belongs in the 4xx range, specifically 400 Bad Request.

The bug is that unvalidated input turns a client mistake into a server crash. This Flask handler reads the field directly:

@app.post("/api/users")
def create_user():
    data = request.get_json(silent=True) or {}
    # BUG: data["email"] raises KeyError when the field is missing,
    # which Flask turns into a 500 Internal Server Error.
    email = data["email"]
    user_id = next(_next_id)
    USERS[user_id] = {"id": user_id, "email": email}
    return jsonify(USERS[user_id]), 201

Send a body with no email and data["email"] throws KeyError. Flask catches the unhandled exception and returns 500. The client learns nothing about what it did wrong, dev environments leak a stack trace, and in production a 500 pages your on-call for what is actually a routine bad request.

Validate before you use the field

Check for the field first and return 400 with a message before touching it. This is the fix from the project:

@app.post("/api/users")
def create_user():
    data = request.get_json(silent=True) or {}
    if not data.get("email"):
        return jsonify(error="email is required"), 400
    email = data["email"]
    user_id = next(_next_id)
    USERS[user_id] = {"id": user_id, "email": email}
    return jsonify(USERS[user_id]), 201

Two details matter. data.get("email") returns None instead of raising when the key is absent, so the check itself never crashes. And the tuple (..., 400) sets the status code - without that second value Flask would default to 200 OK, which is just as wrong in the opposite direction.

The valid path is unchanged: a request with an email still creates the user and returns 201 Created.

Verify both paths with curl

Test the client-error path and the success path explicitly, printing the status code:

pkill -f "python3 app.py"; python3 app.py > /tmp/flask.log 2>&1 &

# Missing email -> 400 (was 500)
curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8000/api/users \
  -H 'Content-Type: application/json' -d '{}'

# Valid request -> 201
curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:8000/api/users \
  -H 'Content-Type: application/json' -d '{"email":"a@b.com"}'

The first call should print 400, the second 201. On the frontend, a React form reading res.status and body.error now shows a precise message ("400: email is required") instead of a generic failure.

The rule that scales

Validate at the edge, before any handler logic touches the input. Real codebases formalize this with schema validation - Pydantic in FastAPI, Zod in TypeScript, Marshmallow in Flask - which auto-returns 400 or 422 with per-field errors so handlers never see unvalidated data. The principle is the same at any scale: a client's bad input is a 4xx, and only an actual server fault earns a 5xx.