Accept-Post general response

What it does

Accept-Post advertises which media types a resource is willing to accept in the body of a POST request — the POST-specific counterpart to Accept-Patch. It exists for the same underlying reason: while POST is often thought of as a generic "send data" method, a specific resource might only meaningfully understand certain formats (a particular JSON schema, a Linked Data format like JSON-LD or Turtle, a specific XML vocabulary), and this header makes that discoverable rather than requiring clients to guess or consult separate documentation.

It sees its heaviest, most standardized real-world use in Linked Data Platform (LDP) and semantic web APIs, where resource creation via POST to a container commonly needs to specify exactly which RDF serialization formats are acceptable.

Syntax

Accept-Post: <media-type>
Accept-Post: <media-type1>, <media-type2>

Example:

Accept-Post: application/ld+json, text/turtle

Like Accept-Patch, most commonly appears on OPTIONS responses as part of capability discovery, though it can appear on other responses too.

How it's used in practice

• Linked Data Platform (LDP) container discovery — an LDP container resource advertises which RDF serialization formats (JSON-LD, Turtle, RDF/XML) it accepts for creating new member resources via POST, letting semantic-web clients discover compatible formats programmatically.
• General API capability discovery — beyond the LDP-specific origin, any API wanting to explicitly communicate which content types a creation endpoint accepts can use Accept-Post the same way Accept-Patch is used for partial updates.
• APIs supporting multiple input formats for resource creation — an endpoint that accepts both JSON and XML representations of a new resource can advertise both via Accept-Post, letting clients choose whichever format suits them.

Common mistakes and gotchas

Assuming Accept-Post is universally implemented across REST APIs. In practice, it's far more consistently seen in Linked Data/semantic web contexts than in general-purpose REST API design, where Content-Type documentation (rather than a discoverable header) remains the more common way developers learn what a POST endpoint expects. Don't assume a typical REST API implements this just because it's a valid, standardized header.

Confusing it with Accept. Accept (a request header) tells the server what response format the client wants back. Accept-Post (a response header) tells the client what request body format the server accepts for POST. They operate in opposite directions and shouldn't be conflated.

Not implementing it consistently across related endpoints. If some POST-accepting endpoints in your API advertise Accept-Post and others don't, clients relying on capability discovery get an inconsistent picture of your API's actual behavior — either implement it broadly or document the format expectations clearly through other means.

Real-world examples

LDP container advertising accepted RDF formats:

OPTIONS /containers/documents HTTP/1.1

HTTP/1.1 204 No Content
Accept-Post: application/ld+json, text/turtle, application/rdf+xml
Allow: GET, POST, OPTIONS

Creating a resource using one of the advertised formats:

POST /containers/documents HTTP/1.1
Content-Type: application/ld+json

{"@context": "https://schema.org", "@type": "Document", "name": "Report"}

HTTP/1.1 201 Created
Location: /containers/documents/abc123

FAQ

What's the difference between Accept-Post and Accept-Patch?

They serve the same discoverable-capability purpose for different methods — Accept-Post advertises accepted body formats for POST (typically resource creation), Accept-Patch does the same for PATCH (partial updates).

Do most REST APIs implement Accept-Post?

Not as consistently as you might expect — it's most strongly and consistently used within Linked Data Platform and semantic web API contexts. General-purpose REST APIs more commonly document accepted POST formats separately rather than exposing this discoverable header, though there's no reason not to use it if you want more self-describing API behavior.

What happens if I POST a format the server doesn't list in Accept-Post?

The server should respond 415 Unsupported Media Type, and ideally include Accept-Post in that error response so the client can see what's actually supported.

Is Accept-Post relevant outside of Linked Data / RDF-based APIs?

It's not restricted to that context by the underlying HTTP spec mechanics — any API can use it to advertise supported POST body formats — it's just that Linked Data Platform is where the header originated and sees its most standardized, consistent real-world usage.

Fun fact

Accept-Post's origin in the W3C's Linked Data Platform specification (rather than a general-purpose IETF HTTP RFC) is a good example of how HTTP's extensibility lets domain-specific communities formalize headers for their own needs without waiting for the core HTTP specification process — the semantic web community needed capability discovery for RDF serialization formats specifically, and rather than that need going unmet, it became a standardized header through a different but equally legitimate standards body.