HTTP 200 OK

The request succeeded and the response carries the representation you asked for. For a GET this is the body; for a PUT or POST it is the result of the operation.

Defined in RFC 9110 §15.3.1 — 200 OK · MDN reference

Where you meet HTTP 200 in production

The default answer to a successful GET, and to a PUT or POST whose result is returned inline. It is the code you will see most and inspect least.

Why you would test it

Worth asserting on more carefully than most suites do: a 200 with the wrong body, a stale representation or a missing header is still a 200, and a status-only assertion will pass it.

What your client should do about a 200

Do not stop at the status line. Validate the body against a schema, check the content type is what you asked for, and confirm any caching headers you rely on are present. A 200 carrying an error object in the body is a real and common API design, and a status-only assertion sails straight past it.

200 versus the codes it gets confused with

Endpoints that return 200

259 endpoints in this playground answer with 200. Every one is free, needs no signup, and can be called from the browser or with curl.

…and 234 more endpoints across the catalog.

Questions about HTTP 200

Can a 200 response contain an error?
Yes, and plenty of APIs do it — a 200 wrapping {"error": …} is common in older SOAP-influenced designs and in some GraphQL setups. It is why an assertion on status alone is weaker than it looks.
Should a POST return 200 or 201?
201 if it created a resource you can address with a URL, 200 if it performed an action and is reporting the outcome.

Other success codes

All HTTP status codes · All 39 mock REST APIs · Getting started guide

Last updated