200 - OK
HTTP 200 OK means the request succeeded and the server is returning a representation of the target resource in the response body.
Last reviewed: March 13, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does OK Mean?
200 confirms transport-layer success but not business-layer correctness — response body, schema, and payload semantics must be validated independently before treating the operation as complete.
Common Causes
- -Cache layer returns a stale 200 with outdated payload after upstream data mutation, so clients read inconsistent state.
- -Upstream service wraps a business error inside a 200 envelope with error fields in the body, masking failure from HTTP-layer monitors.
- -Middleware or API gateway returns 200 for a proxied request that actually failed at the upstream service, because the proxy swallows non-2xx responses and re-wraps them.
How to Fix OK
- 1Validate response body schema and business fields explicitly — do not treat HTTP 200 alone as confirmation of success.
- 2Check upstream service logs when a 200 is returned but downstream behavior is unexpected.
- 3Inspect proxy and gateway access logs to confirm the origin service also returned 2xx before accepting the response as valid.
Step-by-Step Diagnosis for OK
- 1Confirm the HTTP layer reports 200 and cross-check that the response body contains expected fields and values.
- 2Inspect upstream service logs to verify the operation completed successfully end-to-end, not just at the transport layer.
- 3Check whether any middleware, proxy, or gateway in the request path is re-wrapping non-2xx responses as 200.
- 4Validate cache freshness if the response may have been served from a layer that has not yet received the latest upstream data.
Payload and Business Logic Validation
- -Parse and assert required response fields before committing downstream state (example:
orderIdmissing from 200 response body on POST /orders despite transport success). - -Check for error-in-body patterns where status is 200 but payload contains
"error","status": "fail", or equivalent sentinel fields (example: legacy payment gateway wraps decline in HTTP 200).
Proxy and Cache Layer Inspection
- -Trace the full request path to identify any proxy rewriting upstream errors to 200 (example: Nginx
proxy_intercept_errors offcauses upstream 500 to surface as 200 with error body). - -Validate cache TTL and invalidation rules to confirm 200 responses reflect current upstream state (example: CDN serves stale product price after inventory update).
Implementation Examples
curl -i -X GET https://api.example.com/v1/users/123
# Response:
# HTTP/1.1 200 OK
# {"id":"123","name":"Alice","status":"active"}const response = await fetch('https://api.example.com/v1/users/123');
if (response.status === 200) {
const data = await response.json();
if (!data.id || !data.name) {
throw new Error('200 OK but response body is missing required fields');
}
}import requests
response = requests.get('https://api.example.com/v1/users/123')
if response.status_code == 200:
data = response.json()
if 'id' not in data or 'name' not in data:
raise ValueError('200 OK but response body missing required fields')Seen in Production
Payment gateway wraps decline response in HTTP 200
Frequency: common
Example: Checkout service reads HTTP 200 as success and confirms order, but response body contains "result": "declined" — order is created without payment.
Fix: Parse gateway response body explicitly and treat any non-success result field as a failure regardless of HTTP status.
CDN serves stale 200 after backend data update
Frequency: common
Example: Product API returns updated price at origin, but CDN edge node serves cached 200 with old price for up to 5 minutes after cache TTL expires.
Fix: Issue cache purge on data mutations and add Cache-Control headers that align TTL with acceptable staleness window for the resource type.
Debugging Tools
- -curl -i to inspect raw response headers and body together
- -Network tab in browser DevTools for full response payload inspection
- -Distributed tracing (Jaeger, Zipkin, AWS X-Ray) to correlate 200 at gateway with upstream service outcome
- -Response schema validators (Ajv, Pydantic) in integration test suites
How to Verify the Fix
- -Re-run the request and confirm the response body contains all expected fields with correct values.
- -Verify upstream service logs show a successful operation for the same request trace ID.
- -Confirm monitoring and alerting systems correctly distinguish transport-layer 200 from business-layer success.
How to Prevent Recurrence
- -Add contract tests that assert response body shape and required field presence on every 200 response in CI.
- -Configure proxies and gateways to propagate upstream error status codes rather than swallowing them.
- -Instrument business-outcome metrics separately from HTTP status metrics so silent 200 failures are detectable.
Pro Tip
- -build a response-validation middleware layer that rejects 200 responses failing schema contracts before they reach application logic, so transport success never silently masks business failure.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.