Which HTTP status codes should a backend engineer know?

Status codes are part of the contract. Clients, proxies, retry logic and monitoring all read them. A correct code lets a client decide whether to retry, re-authenticate or show a validation message without parsing the body.

The codes that matter most

• 200 OK for a successful read or update with a body
• 201 Created with a Location header for a new resource
• 204 No Content for a successful action with no body
• 400 Bad Request for malformed syntax or invalid parameters
• 401 Unauthorized when authentication is missing or invalid
• 403 Forbidden when the identity is known but not allowed
• 404 Not Found when the resource does not exist or is hidden
• 409 Conflict for a state conflict such as a duplicate or version mismatch
• 422 Unprocessable Content when the body is well-formed but semantically invalid
• 429 Too Many Requests with Retry-After for rate limiting
• 500 Internal Server Error for an unexpected server fault
• 502 Bad Gateway and 503 Service Unavailable for upstream and availability failures

app.post("/users", async (req, res, next) => {
  try {
    const user = await users.create(req.body);
    res.status(201).location("/users/" + user.id).json(user);
  } catch (error) {
    if (error.code === "DUPLICATE_EMAIL") {
      return res.status(409).json({ error: "email_exists" });
    }
    next(error);
  }
});

401 and 403 are commonly confused. 401 means the request lacks valid credentials, so the client may authenticate and retry. 403 means the credentials are valid but the action is not permitted, so retrying with the same identity will not help. 404 can intentionally hide a resource from a user who is not allowed to know it exists.