HTTP POST for APIs: Request Structure and Examples

A form submission that silently fails. An API call is returning 400 Bad Request with no clue why. A file upload that works locally but breaks in production. These problems stem from how POST requests are structured—wrong Content-Type, malformed bodies, or missing headers. Understanding HTTP POST mechanics helps you build reliable API integrations and debug failures faster.

What Is HTTP POST?

HTTP POST is a request method that sends data to a server to create or process a resource. Unlike GET, which retrieves data, POST submits a payload in the request body—form fields, JSON objects, file uploads, or binary content. The server or API endpoint processes this payload and returns an HTTP response indicating success or failure.

POST is the primary method for submitting web forms, creating REST API resources, uploading files, and triggering server-side operations. When you submit a login form or place an order, your browser sends an HTTP POST request.

HTTP POST Request Structure

Every HTTP POST request consists of three parts: the request line, headers, and body. Headers provide metadata about the request, while the body contains the actual data being sent to the server.

HTTP POST Request Example:

┌──────────────────────────────────────────────────────────────┐
│  POST /api/users HTTP/1.1                     ← Request Line │
├──────────────────────────────────────────────────────────────┤
│  Host: api.example.com                        ┐              │
│  Content-Type: application/json               │ Headers      │
│  Content-Length: 52                           ┘              │
├──────────────────────────────────────────────────────────────┤
│  {"username": "dev", "email": "[email protected]"}             │
│                                               ↑ Body         │
└──────────────────────────────────────────────────────────────┘

Two headers are essential for POST requests. Content-Type tells the server how to parse the body. Content-Length specifies the body size in bytes. Omitting these headers causes many frameworks to reject the request or misinterpret the payload.

Content-Type Formats for POST

The Content-Type header determines how the request body is encoded. Choosing the wrong format causes parsers to fail or return empty objects.

Content-Type Use Case Body Format
application/x-www-form-urlencoded HTML forms (default) field1=value1&field2=value2
multipart/form-data File uploads, binary data Boundary-delimited parts
application/json REST APIs, JavaScript apps {"key": "value"}
text/plain Simple text, debugging Raw text body

application/x-www-form-urlencoded

The default encoding for HTML forms. Key-value pairs are joined with &, and special characters are percent-encoded. This HTTP POST example shows a typical login form submission:

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 47

username=john%40example.com&password=secret123

multipart/form-data

Required for file uploads and mixed content. Each field is a separate part delimited by a unique boundary string. The browser generates this boundary automatically when you use <input type="file">.

POST /upload HTTP/1.1
Host: api.example.com
Content-Type: multipart/form-data; boundary=----FormBoundary

------FormBoundary
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

[binary image data]
------FormBoundary--

application/json

Standard for REST APIs. JavaScript's fetch() and most HTTP clients default to JSON when sending objects. Here is a JSON POST request example creating an order:

POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 34

{"product_id": 42, "quantity": 2}

HTTP POST Response Status Codes

API servers respond with status codes that indicate the result of your POST request. Knowing these helps you diagnose problems quickly:

Code Meaning When It Occurs
200 OK Request succeeded Data processed, result in response body
201 Created Resource created New record added; Location header may contain URI
400 Bad Request Invalid syntax Malformed JSON, missing required fields
401 Unauthorized Auth required Missing or invalid credentials
403 Forbidden Access denied Valid auth but insufficient permissions
422 Unprocessable Entity Validation failed Well-formed request, but data fails rules
500 Internal Server Error Server-side failure Unhandled exception or backend error during processing

POST vs GET: When to Use Each

GET retrieves data without side effects. POST modifies server state or creates resources. The following differences determine which method to choose:

  • Data location: GET appends data to the URL. POST sends data in the request body.
  • Size limits: URLs have practical limits around 2,000–8,000 characters. POST bodies have no theoretical limit.
  • Caching: Browsers cache GET responses. POST responses are not cached by default.
  • Idempotency: Repeating GET produces the same result. Repeating POST may create duplicates.

Use GET for fetching data. Use POST for form submissions, API resource creation, and any state-changing operation.

POST vs PUT: Idempotency Matters

POST and PUT both send data but serve different purposes. POST creates a resource at a server-determined URI, while PUT creates or replaces a resource at a client-specified URI. The key distinction is idempotency: POST is not idempotent—sending the same request twice may create two resources. PUT is idempotent—repeated requests leave the server in the same state.

# POST creates new resources (not idempotent)
POST /api/orders     →  Creates order #1001
POST /api/orders     →  Creates order #1002 (duplicate!)

# PUT replaces at specific URI (idempotent)
PUT /api/orders/1001 →  Creates or updates order #1001
PUT /api/orders/1001 →  Same result, no duplicate

Common HTTP POST Problems

When API POST requests fail, the root cause usually falls into these categories:

Wrong Content-Type

Sending JSON with the application/x-www-form-urlencoded content type causes parsers to fail silently. The server receives gibberish or an empty object. Always verify the Content-Type header matches the actual body format—this is the most common cause of 400 errors in API integrations.

Character Encoding Issues

Special characters in form-urlencoded data must be percent-encoded. Unencoded & or = corrupt field boundaries, causing data to split incorrectly. JSON bodies require UTF-8 encoding. If you see garbled text or missing fields, check encoding first.

CORS Preflight Failures

Browser POST requests to cross-origin APIs trigger preflight OPTIONS requests. Without proper Access-Control-Allow-Origin and Access-Control-Allow-Methods headers in the preflight response, the actual POST never executes. The browser console shows a CORS error, but the real fix is on the server.

Request Body Stripped

Proxies, load balancers, or firewalls sometimes strip POST bodies on certain routes. The request arrives with status 200, but the body is empty. This is difficult to diagnose without capturing the raw traffic before and after the proxy.

Debugging API POST Requests with HTTP Debugger

Reproducing POST issues requires seeing exactly what was sent and received. Browser DevTools show JavaScript requests but miss API traffic from desktop apps, backend services, or CLI tools.

captures all HTTP traffic system-wide—browsers, .NET apps, Java applications, and CLI tools. Unlike proxy-based tools, it requires no proxy configuration and captures traffic from apps that bypass system proxy settings.

For POST debugging, HTTP Debugger displays complete requests including headers and body content. The built-in JSON and form-data viewers parse payloads into readable structures. The edit-and-resubmit feature lets you modify headers or body fields and resend immediately.

Frequently Asked Questions

  • Is HTTP POST secure?

    POST is not inherently more secure than GET. The body is hidden from the URL, but travels in plaintext over HTTP. Use HTTPS to encrypt POST data in transit.

  • Can POST requests be cached?

    By default, no. POST responses typically modify server state. However, explicit cache headers can enable caching.

  • What is the maximum POST request size?

    HTTP has no limit. Servers set practical limits — check client_max_body_size (nginx) or maxRequestLength (IIS). Common defaults: 1–100 MB.

  • Why does POST return 405 Method Not Allowed?

    The endpoint exists but does not accept POST. Check API docs — you may need PUT, PATCH, or a different URL.

  • When should I use POST instead of PUT?

    Use POST when the server assigns the resource ID. Use PUT to create or update at a known URI. POST suits non-idempotent actions.



HTTP Debugger

Debug HTTP API calls to a back-end and between back-ends. Very easy to use. Not a proxy, no network issues!

Download Free Trial