HTTP status · 2xx — success
200 OK
200 OK means the request succeeded and the response body contains the representation the client asked for.
Key facts
| Class | 2xx — success |
|---|---|
| Standard | RFC 9110 §15.3.1 |
| Cacheable by default | Yes (heuristic caching allowed) |
| Body | Allowed and expected for GET |
| Idempotent | Inherited from the request method |
What 200 means
The request was understood and completed. For GET and HEAD, 200 is the normal answer and the payload is the requested representation. For POST, 200 means the action succeeded but the response is not necessarily the created resource; 201 is the more precise code when a new resource was created and has a URI.
Why 200 can still hide a problem
Some APIs return 200 with an error object in the body. That is legal HTTP but bad API design: caches treat the response as a success, monitoring cannot count failures, and clients must parse the payload to discover the error. If you control the API, use the matching 4xx or 5xx code and keep the body for details; if you consume one, validate the body rather than trusting the status line.
Frequently asked questions
Is 200 OK an error?
No. It is the standard success code for a completed request.
Can a 200 response be cached?
Yes, unless the response headers say otherwise. A 200 is heuristically cacheable and explicit Cache-Control or Expires headers control the lifetime.
Should a successful API call return 200 or 201?
Use 201 when the request created a resource and you can identify it, usually with a Location header. Use 200 for a successful read or an action that did not create a new resource.