HTTP Error & Status Codes Complete Reference: 400, 401, 403, 405, 409, 418, 422, 425, 429, 500, 502, 503, 504 Explained (2026 Developer Guide)

Every single client-server interaction on the modern web—from a developer executing a cURL request against a REST API to a browser rendering a SaaS dashboard—relies on HTTP Status Codes.

Defined primarily in RFC 9110 (HTTP Semantics) and extended through specifications like RFC 6585, RFC 4918, and RFC 7807, these three-digit integer response codes communicate the exact outcome of an HTTP request.

However, misinterpreting or misconfiguring HTTP status codes is one of the leading causes of silent API failures, broken webhook delivery, search engine de-indexing, and security vulnerabilities.

flowchart TD
    Client["Client / SDK / Browser"] -->|HTTP Request| Proxy["Reverse Proxy / Edge Gateway (Cloudflare / NGINX)"]
    Proxy -->|Routed Request| Origin["Application Server (Node / Python / Go)"]
    
    Origin --> Code1xx["1xx: Informational (100, 101, 103 Early Hints)"]
    Origin --> Code2xx["2xx: Success (200 OK, 201 Created, 204 No Content)"]
    Origin --> Code3xx["3xx: Redirection (301 Permanent, 307/308 Safe Redirects)"]
    Origin --> Code4xx["4xx: Client Error (400, 401, 403, 409, 422, 429)"]
    Proxy --> Code5xx["5xx: Server Error (500, 502 Bad Gateway, 504 Gateway Timeout)"]

In this definitive technical reference, we break down every critical HTTP status code, provide RFC 7807 Problem Details implementations across TypeScript, Python, and Go, analyze rate limiting mechanics (429 Too Many Requests), resolve common confusion between 401 Unauthorized vs 403 Forbidden and 502 Bad Gateway vs 504 Gateway Timeout, and explain how the MailCheck API formats clean REST status codes for high-throughput edge verification.

HTTP Status Code Taxonomy & Standard Classes (RFC 9110)
The 1xx Informational Class: Connection Negotiations
The 2xx Success Class: Execution Confirmed
- 200 OK vs 201 Created vs 202 Accepted vs 204 No Content
The 3xx Redirection Class: URI Routing & SEO Impact
- 301 Moved Permanently vs 302 Found vs 307 vs 308
The 4xx Client Error Suite (Deep Dives & Scenarios)
The 5xx Server Error Suite (Reverse Proxy & Infra Failures)
Standardizing API Errors with RFC 7807 (Problem Details)
Real-World REST API Status Code Reference: MailCheck API Architecture
Frequently Asked Questions (FAQ)
Developer HTTP Status Codes Cheatsheet

1. HTTP Status Code Taxonomy & Standard Classes (RFC 9110)

The Internet Assigned Numbers Authority (IANA) maintains the official registry of HTTP status codes. Every status code is a three-digit integer where the first digit defines the category of the response:

graph TD
    subgraph Status_Taxonomy ["HTTP Status Code Taxonomy (RFC 9110)"]
        C1["1xx: Informational<br/>Request received, continuing process."]
        C2["2xx: Success<br/>Action was successfully received, understood, and accepted."]
        C3["3xx: Redirection<br/>Further action must be taken to complete request."]
        C4["4xx: Client Error<br/>Request contains bad syntax or cannot be fulfilled."]
        C5["5xx: Server Error<br/>Server failed to fulfill an apparently valid request."]
    end

Range	Category	Purpose & Description	Typical Examples
`100–199`	Informational	Interim response while handshake or headers are evaluated.	`100 Continue`, `101 Switching Protocols`, `103 Early Hints`.
`200–299`	Success	The client's request was successfully executed.	`200 OK`, `201 Created`, `204 No Content`.
`300–399`	Redirection	The client must perform additional steps to reach the resource.	`301 Moved Permanently`, `304 Not Modified`, `308 Permanent Redirect`.
`400–499`	Client Error	The client sent an invalid, unauthenticated, or rate-limited payload.	`400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `429 Too Many Requests`.
`500–599`	Server Error	The server encountered an unhandled exception or upstream timeout.	`500 Internal Error`, `502 Bad Gateway`, `504 Gateway Timeout`.

To learn how query parameters pass structured arguments to these endpoints, read our Complete Guide to Query Parameters and API Status Codes.

2. The 1xx Informational Class: Connection Negotiations

Informational status codes indicate that the server has received the initial request headers and the client should continue transmitting the body or switch protocols.

sequenceDiagram
    autonumber
    Client->>Server: POST /upload (Expect: 100-continue)
    Server-->>Client: 100 Continue
    Client->>Server: [Sends 50MB Binary Payload]
    Server-->>Client: 201 Created

100 Continue

When It Occurs: The client sends an Expect: 100-continue header before dispatching a large request payload (e.g., a 100MB file upload).
Engineering Purpose: Allows the server to verify headers (e.g., authentication, permissions) and reply with 100 Continue before the client wastes bandwidth uploading the data.

101 Switching Protocols (WebSockets)

When It Occurs: Sent by the server when upgrading an HTTP/1.1 TCP connection to a full-duplex WebSocket connection via the Upgrade: websocket header.

103 Early Hints (Edge Web Performance)

When It Occurs: Specified in RFC 8297, 103 Early Hints allows the server to return <link rel="preload"> resource headers to the browser while the origin application server is still rendering the HTML response.
Impact: Reduces Largest Contentful Paint (LCP) by 200–500ms on modern edge networks (Cloudflare, Fastly).

3. The 2xx Success Class: Execution Confirmed

graph LR
    subgraph Success_Codes ["2xx Success Class Operations"]
        R200["200 OK<br/>Standard Read/Update with Body"]
        R201["201 Created<br/>POST Resource Created + Location Header"]
        R202["202 Accepted<br/>Async Job Queued (Kafka/Celery)"]
        R204["204 No Content<br/>DELETE / PUT Success (Empty Body)"]
    end

200 OK vs 201 Created vs 202 Accepted vs 204 No Content

200 OK: The standard response for successful GET, PUT, or PATCH operations returning a JSON payload.
201 Created: The mandatory REST standard for successful POST operations that instantiate a new entity. Should include a Location: /api/v1/users/usr_99 header pointing to the new resource.
202 Accepted: Used in asynchronous architectures (e.g., batch email verification). The server accepts the payload into a message queue (SQS, RabbitMQ, Redis) for background processing, returning a job_id.
204 No Content: The operation succeeded, but the response body is intentionally empty (standard for DELETE operations).

4. The 3xx Redirection Class: URI Routing & SEO Impact

Redirection status codes instruct the client (browser, crawler, or API consumer) to locate the requested resource at a different URL.

graph TD
    subgraph Redirect_Decision_Tree ["HTTP Redirect Strategy Tree"]
        P{"Is the move Permanent or Temporary?"}
        P -->|Permanent| M1{"Must preserve HTTP Method?"}
        P -->|Temporary| M2{"Must preserve HTTP Method?"}
        
        M1 -->|No (Permits POST->GET)| R301["301 Moved Permanently (SEO Canonical)"]
        M1 -->|Yes (Guarantees POST->POST)| R308["308 Permanent Redirect (Modern REST APIs)"]
        
        M2 -->|No (Permits POST->GET)| R302["302 Found (Legacy Browser)"]
        M2 -->|Yes (Guarantees POST->POST)| R307["307 Temporary Redirect (Modern REST APIs)"]
    end

301 Moved Permanently vs 302 Found vs 307 vs 308

Status Code	RFC Standard	Reusable / Cached	Preserves HTTP Method (`POST` -> `POST`)	SEO Link Equity (PageRank)
`301 Moved Permanently`	RFC 9110	✅ Yes	❌ No (Historic clients rewrite `POST` to `GET`)	Transfers 100% Equity
`302 Found`	RFC 9110	❌ No	❌ No (Rewrites `POST` to `GET`)	0% Equity Transfer
`307 Temporary Redirect`	RFC 9110	❌ No	✅ Yes (Guarantees same HTTP method)	0% Equity Transfer
`308 Permanent Redirect`	RFC 7538	✅ Yes	✅ Yes (Guarantees same HTTP method)	Transfers 100% Equity

Architectural Recommendation: For public REST APIs, always use 307 and 308 instead of 301/302 to prevent API clients from accidentally converting POST or PUT payloads into empty GET requests.

5. The 4xx Client Error Suite (Deep Dives & Scenarios)

The 4xx family signifies that the client has submitted a request that violates protocol syntax, authorization constraints, rate limits, or business rules.

graph LR
    subgraph Client_Errors ["Critical 4xx Client Error Suite"]
        E400["400 Bad Request<br/>Malformed JSON / Params"]
        E401["401 Unauthorized<br/>Missing / Invalid Token"]
        E403["403 Forbidden<br/>Valid Auth, Insufficient Role"]
        E409["409 Conflict<br/>Database Duplicate / Lock"]
        E422["422 Unprocessable<br/>Semantic Schema Failure"]
        E429["429 Too Many Requests<br/>Rate Limit Exceeded"]
    end

400 Bad Request

Trigger: Malformed JSON syntax, invalid query parameters, or mismatched data types in the request envelope.
Example: Submitting unquoted JSON or passing a string into an integer parameter:

// POST /api/v1/verify
// Server receives: { email: "alex@company.com", timeout: "invalid_int" }
// Response: 400 Bad Request
{
  "type": "https://api.mailcheck.fadsync.com/errors/bad-request",
  "title": "Invalid Request Syntax",
  "status": 400,
  "detail": "Parameter 'timeout' must be an integer between 1000 and 10000."
}

401 Unauthorized vs 403 Forbidden (Auth Architecture)

The naming of 401 Unauthorized is historically unfortunate: 401 represents unauthenticated, while 403 represents unauthorized.

sequenceDiagram
    autonumber
    actor Client
    participant API as Secure REST API
    
    Note over Client,API: Scenario A: Missing / Invalid API Key
    Client->>API: GET /api/v1/account (No Bearer Token)
    API-->>Client: 401 Unauthorized (WWW-Authenticate: Bearer realm="api")
    
    Note over Client,API: Scenario B: Authenticated User lacks Admin Scope
    Client->>API: DELETE /api/v1/users/99 (Token: Role="viewer")
    API-->>Client: 403 Forbidden (Auth verified, but role insufficient)

401 Unauthorized: The client has not supplied valid authentication credentials (e.g., missing or expired Bearer token). The response MUST include a WWW-Authenticate header.
403 Forbidden: The server understands who the client is (authentication succeeded), but refuses authorization because the client lacks required permissions (e.g., a standard user attempting to access /admin/billing).

404 Not Found vs 410 Gone (API Lifecycle & SEO)

404 Not Found: The resource does not exist at the requested URI. This may be temporary.
410 Gone: The resource has been permanently deleted and will never return.
SEO Impact: Search engine crawlers (Googlebot) retry 404 pages multiple times before removing them from the index. When receiving a 410 Gone, Googlebot drops the URL from the index immediately, saving crawler budget.

405 Method Not Allowed

Trigger: A client attempts an HTTP verb not supported by the route (e.g., executing POST on a read-only /status health endpoint).
Protocol Requirement: The server MUST return an Allow header listing permitted methods (e.g., Allow: GET, HEAD, OPTIONS).

408 Request Timeout vs 409 Conflict

408 Request Timeout: The client established a TCP connection but failed to transmit the complete HTTP request before the server's idle timeout expired.
409 Conflict: The request could not be completed due to a state conflict on the target resource (e.g., attempting to register an email address that already exists in the database, or an optimistic locking version collision).

418 I'm a Teapot (RFC 2324 & Modern Security Applications)

Defined on April Fools' Day 1998 in RFC 2324 (Hyper Text Coffee Pot Control Protocol), 418 I'm a Teapot was designed as a humorous extension for networked coffee pots refusing to brew tea.

Modern Security Engineering Use Case:

In 2026, many Web Application Firewalls (WAFs) and honeypot systems intentionally return HTTP 418 to automated scrapers and vulnerability scanners (e.g., SQLmap) that probe hidden administrative endpoints.

flowchart LR
    Bot["Malicious Scraper / Bot"] -->|GET /wp-admin/setup-config.php| WAF["Edge Honeypot / Cloudflare Worker"]
    WAF -->|Detects Automated Fingerprint| Teapot["HTTP 418 I'm a Teapot: Honeypot Triggered"]

422 Unprocessable Entity (Semantic Validation)

Introduced in RFC 4918 and formalized in RFC 9110, 422 Unprocessable Entity is the gold standard for semantic schema validation errors.

Difference from 400 Bad Request: The request JSON syntax is 100% well-formed, but the business values fail domain validation rules (e.g., an invalid email format failing RFC 5322 regex).

// HTTP 422 Unprocessable Entity
{
  "type": "https://api.mailcheck.fadsync.com/errors/validation",
  "title": "Unprocessable Entity",
  "status": 422,
  "invalid_params": [
    {
      "name": "email",
      "reason": "Email string 'alex..smith@company' fails RFC 5322 syntax validation."
    }
  ]
}

For a comprehensive guide on validating email regular expressions, read our Email Validation Regex & RFC 5322 Standards Masterclass.

425 Too Early (TLS 1.3 0-RTT Anti-Replay)

Defined in RFC 8470, 425 Too Early protects web servers against 0-RTT (Zero Round Trip Time) Replay Attacks in TLS 1.3.

When a client resumes a TLS session using early data, an eavesdropper can capture and retransmit non-idempotent HTTP requests (like POST /api/v1/charge-credit-card). When an origin server detects non-idempotent requests in early data, it returns 425 Too Early, prompting the client to retry only after the TLS handshake completes.

429 Too Many Requests & Rate Limiting Headers

Defined in RFC 6585, 429 Too Many Requests indicates that the client has exceeded their allocated rate limits within a given time window.

sequenceDiagram
    autonumber
    Client->>API: POST /v1/verify (Request #101 in 1 minute)
    API-->>Client: 429 Too Many Requests
    Note over API,Client: Headers:<br/>Retry-After: 30<br/>X-RateLimit-Limit: 100<br/>X-RateLimit-Remaining: 0<br/>X-RateLimit-Reset: 1754400030

Standard Rate Limiting Response Headers:

Retry-After: Number of seconds the client must wait before making another request (e.g., Retry-After: 30).
X-RateLimit-Limit: The maximum requests allowed in the current window (e.g., 1000).
X-RateLimit-Remaining: Number of remaining requests in the current window (0).
X-RateLimit-Reset: Unix timestamp (seconds) when the quota resets.

6. The 5xx Server Error Suite (Reverse Proxy & Infra Failures)

The 5xx family indicates that the server encountered an error preventing it from fulfilling an otherwise valid request.

graph TD
    subgraph Server_Errors ["5xx Infrastructure Error Architecture"]
        E500["500 Internal Server Error<br/>Application Crash / Uncaught Exception"]
        E502["502 Bad Gateway<br/>Reverse Proxy received invalid upstream response"]
        E503["503 Service Unavailable<br/>Server overloaded or in maintenance"]
        E504["504 Gateway Timeout<br/>Upstream application took too long to reply"]
    end

500 Internal Server Error

Cause: An unhandled exception or runtime panic within application code (e.g., NullPointerException, uncaught Promise rejection, database connection pool exhaustion).
Resolution: Check server-side application logs (Datadog, Sentry, CloudWatch). Never expose raw stack traces to end-users in production.

502 Bad Gateway vs 504 Gateway Timeout

Understanding the distinction between 502 and 504 is fundamental to debugging distributed systems:

sequenceDiagram
    autonumber
    participant Browser as Client Browser
    participant Nginx as Reverse Proxy (NGINX / Cloudflare)
    participant Node as Upstream App (Node.js / Go)
    
    Note over Browser,Node: Scenario A: 502 Bad Gateway
    Browser->>Nginx: GET /api/v1/users
    Nginx->>Node: TCP Connect Port 3000
    Node-->>Nginx: [Process Crashes / Connection Refused]
    Nginx-->>Browser: 502 Bad Gateway (Upstream sent invalid response)
    
    Note over Browser,Node: Scenario B: 504 Gateway Timeout
    Browser->>Nginx: GET /api/v1/heavy-export
    Nginx->>Node: Forward Request
    Note over Node: SQL Query hangs for 65 seconds (Proxy timeout = 60s)
    Nginx-->>Browser: 504 Gateway Timeout (Upstream failed to respond in time)

502 Bad Gateway: The reverse proxy (NGINX, Cloudflare, AWS ALB) received an invalid or empty response from the upstream application server (e.g., the Node.js process crashed immediately or refused the TCP connection).
504 Gateway Timeout: The reverse proxy connected to the upstream application, but the upstream application took longer than the configured proxy timeout (e.g., proxy_read_timeout 60s) to complete execution.

503 Service Unavailable & Circuit Breakers

Cause: The server is temporarily unable to handle the request due to maintenance or extreme traffic spikes.
Circuit Breaker Integration: In microservice architectures, when a downstream database or third-party service fails, a circuit breaker trips and immediately returns 503 Service Unavailable with a Retry-After: 60 header, preventing cascade failures across the entire cluster.

7. Standardizing API Errors with RFC 7807 (Problem Details)

Modern REST API architectures should never return generic plain-text error messages. RFC 7807 (Problem Details for HTTP APIs) defines a standard JSON schema for machine-readable error responses.

{
  "type": "https://api.mailcheck.fadsync.com/errors/rate-limit-exceeded",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "You have exceeded your plan rate limit of 100 requests per minute.",
  "instance": "/api/v1/verify?email=alex@company.com",
  "retry_after_seconds": 24
}

Below are complete implementations of RFC 7807 error middleware across major server runtimes:

TypeScript / Express / Fastify

import { Request, Response, NextFunction } from 'express';

export interface RFC7807Problem {
  type: string;
  title: string;
  status: number;
  detail: string;
  instance?: string;
  errors?: Record<string, string[]>;
}

export class APIError extends Error {
  constructor(
    public status: number,
    public title: string,
    public detail: string,
    public type: string = 'about:blank',
    public validationErrors?: Record<string, string[]>
  ) {
    super(detail);
  }
}

export function rfc7807ErrorHandler(
  err: Error,
  req: Request,
  res: Response,
  next: NextFunction
) {
  if (err instanceof APIError) {
    const payload: RFC7807Problem = {
      type: err.type,
      title: err.title,
      status: err.status,
      detail: err.detail,
      instance: req.originalUrl,
      ...(err.validationErrors && { errors: err.validationErrors })
    };

    return res
      .status(err.status)
      .setHeader('Content-Type', 'application/problem+json')
      .json(payload);
  }

  // Fallback 500 Handler
  return res.status(500).setHeader('Content-Type', 'application/problem+json').json({
    type: 'https://api.example.com/errors/internal-server-error',
    title: 'Internal Server Error',
    status: 500,
    detail: 'An unexpected error occurred. Please contact support.',
    instance: req.originalUrl
  });
}

Python / FastAPI / Starlette

from fastapi import FastAPI, Request, status
from fastapi.responses import JSONResponse
from pydantic import BaseModel
from typing import Optional, Dict, List

app = FastAPI()

class RFC7807Exception(Exception):
    def __init__(
        self,
        status_code: int,
        title: str,
        detail: str,
        type_uri: str = "about:blank",
        errors: Optional[Dict[str, List[str]]] = None
    ):
        self.status_code = status_code
        self.title = title
        self.detail = detail
        self.type_uri = type_uri
        self.errors = errors

@app.exception_handler(RFC7807Exception)
async def problem_details_handler(request: Request, exc: RFC7807Exception):
    payload = {
        "type": exc.type_uri,
        "title": exc.title,
        "status": exc.status_code,
        "detail": exc.detail,
        "instance": str(request.url)
    }
    if exc.errors:
        payload["errors"] = exc.errors
        
    return JSONResponse(
        status_code=exc.status_code,
        content=payload,
        media_type="application/problem+json"
    )

Go (Golang Standard Library)

package main

import (
	"encoding/json"
	"net/http"
)

type ProblemDetails struct {
	Type     string              `json:"type"`
	Title    string              `json:"title"`
	Status   int                 `json:"status"`
	Detail   string              `json:"detail"`
	Instance string              `json:"instance,omitempty"`
	Errors   map[string][]string `json:"errors,omitempty"`
}

func WriteProblemDetails(w http.ResponseWriter, r *http.Request, problem ProblemDetails) {
	problem.Instance = r.URL.RequestURI()
	w.Header().Set("Content-Type", "application/problem+json")
	w.WriteHeader(problem.Status)
	json.NewEncoder(w).Encode(problem)
}

func ExampleHandler(w http.ResponseWriter, r *http.Request) {
	apiKey := r.Header.Get("Authorization")
	if apiKey == "" {
		WriteProblemDetails(w, r, ProblemDetails{
			Type:   "https://api.example.com/errors/unauthorized",
			Title:  "Unauthorized",
			Status: http.StatusUnauthorized,
			Detail: "Missing required Bearer authentication token in Authorization header.",
		})
		return
	}
	// Execution continues...
}

8. Real-World REST API Status Code Reference: MailCheck API Architecture

The MailCheck API executes email verification at the global edge in under 65 milliseconds, adhering strictly to REST status code specifications:

graph TD
    ClientReq["Incoming cURL / SDK Request: GET /v1/verify?email=..."] --> Gate{"API Gateway Validation"}
    
    Gate -->|Missing API Key| SC401["401 Unauthorized (Invalid API Key)"]
    Gate -->|Rate Limit Exceeded| SC429["429 Too Many Requests (Retry-After: 30)"]
    Gate -->|Malformed Syntax| SC400["400 Bad Request (Missing Email Param)"]
    Gate -->|Valid Envelope| Process["Global Edge Verification Engine"]
    
    Process -->|Verification Complete| SC200["200 OK (Clean Deliverability Payload)"]

HTTP Status Code	Scenario in MailCheck API	Example API Response Structure
`200 OK`	Email verification executed successfully.	`{"status": "valid", "score": 98, "is_disposable": false}`
`400 Bad Request`	Missing required `?email=` query parameter.	`{"title": "Bad Request", "detail": "Query param 'email' required"}`
`401 Unauthorized`	Invalid or missing `Bearer` API token.	`{"title": "Unauthorized", "detail": "Invalid API key provided"}`
`403 Forbidden`	Account quota depleted (0 credits remaining).	`{"title": "Quota Exceeded", "detail": "Please upgrade your credit tier"}`
`429 Too Many Requests`	Plan burst rate limit exceeded.	`{"title": "Rate Limit Exceeded", "retry_after": 20}`
`500 Internal Error`	Upstream edge worker exception.	`{"title": "Internal Error", "detail": "Edge worker timeout"}`

Test live single verifications using our free MailCheck Interactive Email Validator.

9. Frequently Asked Questions (FAQ)

What is the difference between `401 Unauthorized` and `403 Forbidden`?

401 Unauthorized means the client is unauthenticated (missing or invalid credentials). 403 Forbidden means the client is authenticated, but the server refuses access because the user lacks the necessary authorization permissions or roles.

Why should I use `422 Unprocessable Entity` instead of `400 Bad Request`?

400 Bad Request indicates that the server could not parse the syntax of the request (e.g., malformed JSON). 422 Unprocessable Entity indicates that the JSON syntax was perfectly valid, but the payload contained semantic validation errors (e.g., an age field containing a negative integer or an invalid email format).

How should clients handle an `HTTP 429 Too Many Requests` response?

Clients should read the Retry-After header returned in the response and pause subsequent outgoing requests for that duration. In automated SDKs, implement an exponential backoff algorithm with full jitter to prevent thundering herd problems.

Is `HTTP 418 I'm a Teapot` an official HTTP status code?

Yes, it was officially specified in RFC 2324 in 1998 as an April Fools' joke. However, it is officially recognized by IETF and node engines, and is actively used in modern web security systems to flag honeypot hits.

What is the difference between `502 Bad Gateway` and `504 Gateway Timeout`?

502 Bad Gateway means a proxy server received an invalid, malformed, or empty response from the upstream application. 504 Gateway Timeout means the proxy connected to the upstream application, but the application failed to return a response before the proxy's read timeout expired.

10. Developer HTTP Status Codes Cheatsheet

================================================================================
                    DEVELOPER HTTP STATUS CODES CHEATSHEET
================================================================================
INFORMATIONAL (1xx):
  100 Continue            Client may proceed with payload upload.
  101 Switching Protocols Upgrading connection to WebSocket.
  103 Early Hints         Preload CSS/JS assets before HTML rendering.

SUCCESS (2xx):
  200 OK                  Standard successful GET / PUT / PATCH.
  201 Created             POST created new resource (include Location header).
  202 Accepted            Async job accepted into background queue.
  204 No Content          Operation succeeded; no response body (DELETE).

REDIRECTION (3xx):
  301 Moved Permanently   Permanent URL migration (100% SEO Link Equity).
  304 Not Modified        Client cache is valid (ETag / If-Modified-Since).
  307 Temporary Redirect  Redirects preserving POST/PUT HTTP verb.
  308 Permanent Redirect  Permanent redirect preserving POST/PUT HTTP verb.

CLIENT ERRORS (4xx):
  400 Bad Request         Malformed JSON / invalid query parameter syntax.
  401 Unauthorized        Missing or invalid authentication credentials.
  403 Forbidden           Authenticated user lacks permission.
  404 Not Found           Resource does not exist.
  405 Method Not Allowed  HTTP verb not supported (include Allow header).
  409 Conflict            Resource state conflict / database duplicate.
  410 Gone                Resource permanently deleted (Drops SEO index).
  418 I'm a Teapot        Honeypot trigger / RFC 2324.
  422 Unprocessable       Semantic schema validation error (RFC 4918).
  425 Too Early           Replay attack prevention in TLS 1.3 0-RTT.
  429 Too Many Requests   Rate limit exceeded (include Retry-After header).

SERVER ERRORS (5xx):
  500 Internal Error      Unhandled application exception / runtime panic.
  502 Bad Gateway         Reverse proxy received invalid upstream response.
  503 Service Unavailable Temporary overload or maintenance (Circuit breaker).
  504 Gateway Timeout     Upstream application failed to respond in time.
================================================================================

Build Resilient, High-Performance API Pipelines Today

🧪 Live Validation: Test email addresses via our MailCheck Validator.
📚 API Reference: Explore our Developer Documentation.
💰 Transparent Pricing: Check out our plans on the Pricing Page.
🔍 Related Masterclasses: Read our Query Parameters & API Design Guide and Email Validation Regex & RFC 5322 Guide.