API Returns 200 for Validation Failure

When an API endpoint receives invalid input and returns HTTP 200 OK instead of an appropriate 4xx status code, the client cannot distinguish a successful operation from a failed one by checking the HTTP status alone. Error information is buried in the response body, breaking clients that rely on standard HTTP semantics.

HighBeginnerAPI testingManual testingAutomated testing

// UNDERSTAND

// Symptoms

Submitting a form with invalid data shows no error because the API returned 200
The response body contains an error message (e.g. { status: 'error', message: '...' }) but the HTTP status is 200
Monitoring systems that alert on non-2xx responses do not detect the validation failure
A client library that checks HTTP status before parsing the body silently treats the failure as success
Automated tests that assert HTTP 200 pass despite the request failing validation

// Root Cause

The validation logic runs but the error is caught in a handler that returns HTTP 200 with an error payload instead of a 4xx status
A middleware or global exception handler was configured to always return 200 to avoid breaking a downstream client — the error is communicated through a body-level status field instead
The endpoint pre-dates standardized REST error handling and was designed to always return 200, with success or failure signalled only through the response body

// Where It Appears

Form submission endpoints that return a JSON body with an error flag
Legacy REST APIs designed before HTTP status codes were consistently applied
Payment or order processing endpoints where the upstream service always returns 200
Endpoints consumed by clients that parse a body-level status field rather than checking HTTP status

// REPRODUCE & TEST

// How to Reproduce

01Identify an endpoint that validates required fields (e.g. POST /api/orders requires a customerId field)
02Construct a valid request body, then remove the customerId field
03Send the POST /api/orders request with the field omitted
04Observe the HTTP response status code
05Read the response body and note whether it contains an error message despite the 200 status

// Test Data Needed

The API endpoint URL and the list of its required or validated fields
A valid bearer token for authentication
A way to send raw HTTP requests with controlled payloads (Postman, curl, or browser DevTools)

// Manual Testing Ideas

Submit a form with each required field omitted one at a time and check the HTTP status code in DevTools
Send a request with an invalid field type (e.g. a string where an integer is expected) and observe the status
Submit a value that violates a range constraint (e.g. quantity: -1) and verify the status is 4xx
Check whether the response body's error message accurately names the failing field
Compare the API behavior against its documented OpenAPI or JSON Schema to identify undocumented 200 errors

// API Testing Ideas

To confirm the bug, send each invalid variation below and check the actual status returned — 400 or 422 means the API is correct; 200 means the bug is present
Send a valid POST /api/orders with all required fields present; assert the response is 201 Created
Send the same request with the customerId field omitted
Assert the HTTP status is 400 Bad Request — not 200
Send a request with an invalid field type (e.g. quantity: 'abc')
Assert the response is 400 and the body names the invalid field
Send an empty body {} to the same endpoint
Assert the status is 400 — not 200

// Automation Idea

Parametrize a test suite that sends one invalid variation per test case — omit each required field, use each wrong type, supply each boundary-violating value. For every case, assert the HTTP status is 4xx. Flag any case that returns 200 as a failure.

// Expected Result

When input validation fails, the API returns 400 Bad Request or 422 Unprocessable Entity with a body identifying the failing field and the reason.

// Actual Result (Example)

A POST /api/orders request with the customerId field omitted returns HTTP 200 OK with body { "status": "error", "message": "customerId is required" }.

// REPORT IT

Example Bug Report

Title: POST /api/orders returns 200 OK when required field customerId is missing
Severity: High
Environment: Staging environment Postman Valid bearer token
Steps to Reproduce: 01Obtain a valid bearer token by authenticating as a standard user
02Send POST /api/orders with a valid body but with the customerId field omitted
03Observe the HTTP response status code and response body
Expected Result: The API returns 400 Bad Request with a message identifying the missing customerId field.
Actual Result: The API returns 200 OK with body { "status": "error", "message": "customerId is required" }.
Impact: Clients that check HTTP status before parsing the body silently treat validation failures as success, causing incomplete orders to be processed downstream and corrupting order data.