What do HTTP status codes mean?

HTTP status codes are three-digit numbers an API returns to indicate the result of a request. They are grouped by first digit: 2xx means success, 3xx means redirection, 4xx means a client error (the request was wrong), and 5xx means a server error (the server failed). The specific code refines the meaning, such as 200 OK, 201 Created, 400 Bad Request, 404 Not Found, and 500 Internal Server Error.

What is the difference between 200 and 202?

200 OK means the request succeeded and the result is complete and returned. 202 Accepted means the request was accepted for processing but is not yet complete, the work happens asynchronously afterward. The distinction matters in payments: a 202 on a payment submission means the payment was received but not yet validated or settled, so the caller must not treat it as confirmation that the payment succeeded.

What does HTTP 409 Conflict mean?

409 Conflict means the request could not be completed because it conflicts with the current state of the resource. A common use is duplicate detection: submitting a request with an idempotency key that was already used returns 409 to indicate the resource already exists or the operation was already performed. It signals the client that the conflict must be resolved, rather than a generic failure.

Why do status codes matter for analysts?

Status codes matter because they are part of the API contract and define how the system communicates results, which analysts must specify in requirements and verify in testing. Knowing what each code means lets you write accurate API requirements, design correct test assertions, interpret what an API is really telling you, and reason about behavior such as the difference between received and completed. Misunderstanding a code leads to wrong requirements and missed defects.

What is the difference between 4xx and 5xx errors?

4xx errors indicate a client error, meaning something was wrong with the request, such as invalid data (400), missing authentication (401), no permission (403), or a missing resource (404); the client should fix the request. 5xx errors indicate a server error, meaning the request may have been valid but the server failed to handle it, such as an internal error (500) or an unavailable service (503); the client cannot fix it by changing the request.

HTTP Status Codes Explained: What 200, 202, and 409 Really Mean

HTTP status codes are how an API tells you what happened, and the difference between a 200 and a 202, or a 400 and a 500, carries real meaning. For an analyst, knowing the codes is the difference between specifying and testing an API correctly and misreading what it is telling you.

HTTP status codes are three-digit numbers an API returns to indicate the result of a request, grouped by their first digit: 2xx is success, 3xx is redirection, 4xx is a client error meaning the request was wrong, and 5xx is a server error meaning the server failed. The specific code refines the meaning, 200 OK, 201 Created, 202 Accepted, 400 Bad Request, 401 Unauthorized, 404 Not Found, 409 Conflict, 500 Internal Server Error, and each carries information an analyst needs to specify requirements and verify behavior correctly. The codes are part of the API contract, so misunderstanding one leads to wrong requirements and missed defects, while knowing them lets you read what an API is actually telling you. This is practical developer analyst knowledge that underpins API testing and writing API requirements.

You do not need to memorize the full list of codes; you need to understand the families and the dozen or so that come up constantly, plus the few distinctions that matter in payments. The deeper treatment of API behavior is in API Documentation from Scratch.

What do the status code families mean?

The first digit tells you the category of outcome, and learning the four families gives you the framework to interpret any code, even ones you have not seen. The families are 2xx success, 3xx redirection, 4xx client error, and 5xx server error.

2xx Success means the request was received, understood, and accepted. The work succeeded, though, as we will see, “succeeded” can mean completed or just accepted for processing. 3xx Redirection means further action is needed to complete the request, usually that the resource is elsewhere; analysts encounter these less often in API work. 4xx Client Error means the request itself was wrong, bad data, missing authentication, no permission, a resource that does not exist, and the fix is on the client’s side: change the request. 5xx Server Error means the request may have been fine but the server failed to handle it, an internal error or an unavailable dependency, and the client cannot fix it by changing the request; the problem is server-side.

The 4xx-versus-5xx distinction is the most useful one to internalize, because it tells you where the problem is and who can fix it. A 4xx says “you sent something wrong, correct it,” which in testing means your request was invalid, possibly by design if you were testing a rejection. A 5xx says “the server broke,” which is almost always a defect worth raising, because a valid request should never produce a 5xx. Knowing this lets you immediately triage what an API response means, which is the foundation of reading API behavior and the logs behind it.

Why does 202 versus 200 matter so much in payments?

The difference between 200 and 202 is the difference between “done” and “received but not yet done,” and in payments that distinction is critical, because treating a 202 as confirmation that a payment succeeded is a serious error. A 200 means complete; a 202 means accepted for asynchronous processing that has not finished.

When you submit a payment and get a 200 OK, the operation is complete and the result is returned, the request fully succeeded. When you get a 202 Accepted, the request was accepted for processing but the work happens asynchronously afterward and is not yet done. In a typical payment flow, submission returns 202: the system received and acknowledged the payment, but it has not yet validated, processed, or settled it, that all happens behind the scenes through events. The payment could still be rejected downstream for a closed account or insufficient funds, even though you got a 202. So a 202 means “we have your request,” not “your payment succeeded,” and a caller that treats it as success will tell the customer their money moved when it has not.

This is why I flag the 202-versus-200 distinction as a requirement-level concern, not a technical footnote. It directly shapes what the customer should be told: after a 202, the correct message is “payment received” or “in progress,” and the customer must then poll or be notified of the real outcome, which connects to the synchronous versus asynchronous design and the status communication it requires. Getting this wrong produces exactly the notify-before-the-ledger-posts defect that erodes customer trust. Specifying that a payment submission returns 202 and what each subsequent status means is core functional analysis, and verifying the real code the system returns is a standard API test assertion.

What do the common error codes tell you?

The common error codes each carry a specific meaning that an analyst should know on sight, because they appear constantly in requirements and testing. The ones worth knowing cold are 400, 401, 403, 404, 409, 422, 500, and 503.

400 Bad Request means the request was malformed or invalid, bad syntax, a missing required field, an unparseable body. 401 Unauthorized means authentication is missing or invalid, you have not proven who you are. 403 Forbidden means you are authenticated but not allowed to do this, a permissions problem. 404 Not Found means the resource does not exist. 409 Conflict means the request conflicts with the current state, classically used for duplicate detection: a repeated request with an already-used idempotency key returns 409 to say the operation already happened. 422 Unprocessable Entity means the request was well-formed but failed semantic validation, often used when the data is syntactically valid but breaks a business rule. 500 Internal Server Error means the server hit an unexpected failure. 503 Service Unavailable means the server is temporarily unable to handle the request, often a downstream dependency being down.

400  malformed / invalid request
401  not authenticated
403  authenticated but not permitted
404  resource not found
409  conflict (e.g. duplicate idempotency key)
422  valid format, failed business validation
500  server error (usually a defect)
503  service unavailable (often transient)

These map directly onto the failure paths you specify and test. A duplicate payment returning 409 is the idempotency behavior; an invalid field returning 400 and a business-rule failure returning 422 are distinct rejection paths in your error contract; a 401 versus 403 distinction is an authentication-versus-authorization requirement. Knowing the codes lets you specify each failure with the right code and assert it precisely in testing, which is the difference between an error contract that is correct and one that is vague.

How does knowing status codes make you better at the job?

Knowing status codes makes you better because they are part of the contract you specify, the responses you test, and the behavior you interpret, so fluency in them improves your requirements, your tests, and your diagnosis. It is a small body of knowledge with constant application.

When writing requirements, you specify the exact code for each outcome, 202 for accepted, 400 for invalid input, 409 for a duplicate, so the API requirement is precise and the developer builds the right responses. When testing, you assert the exact code, catching the defect where the system returns 200 when it should return 202, or 500 when it should return 400, which are real and common bugs. When interpreting an API’s behavior, whether reading a contract, debugging a flow, or reading logs, the code tells you immediately what happened and where the problem lies, a 5xx is a server defect, a 4xx is a request problem, a 202 is asynchronous in-progress.

This fluency is part of the broader self-sufficiency that defines the technical business analyst: you read what the system is telling you directly, rather than asking someone to interpret it. Combined with reading API contracts, understanding JSON payloads, and the rest of the developer analyst toolkit, knowing status codes lets you reason about API behavior as a peer to the engineers. It is a small investment, a dozen codes and four families, with outsized return across every integration you ever specify or test, and it is part of the foundation in The Technical Skills Guide for BAs.

The takeaway

HTTP status codes are how an API reports the result of a request, grouped into 2xx success, 3xx redirection, 4xx client error, and 5xx server error, with specific codes refining the meaning. The distinctions that matter most for analysts are 4xx versus 5xx (whose problem is it) and 202 versus 200 (received versus done), the latter being critical in payments where a 202 must never be treated as confirmation. Learn the dozen common codes and you can specify, test, and interpret API behavior accurately.

It is a small body of knowledge that pays off in every requirement, test, and diagnosis you do. Start with API Documentation from Scratch and The Technical Skills Guide for BAs, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: API, Technical Skills, HTTP, Software Testing, Career Growth