Preference-Applied general response

What it does

Preference-Applied is the server's way of confirming which of the client's requested Prefer preferences it actually honored on a given response. Since Prefer is explicitly advisory (a server can support, partially support, or ignore any given preference), Preference-Applied closes the feedback loop — without it, a client sending Prefer: return=minimal has no reliable, standardized way to know whether the server actually processed that preference or just happened to send a response that looked minimal for unrelated reasons.

Syntax

Preference-Applied: <preference>
Preference-Applied: <preference1>, <preference2>

Lists whichever preferences from the corresponding request's Prefer header the server actually applied — preferences that weren't honored are simply omitted, rather than explicitly listed as "not applied."

How it's used in practice

• Confirming return=minimal was honored — a client that requested a minimal response can check for Preference-Applied: return=minimal to confirm the empty/minimal body it received was intentional server behavior, not an unrelated error or unexpected response shape.
• Confirming async processing kicked in — after sending Prefer: respond-async, a client checks for Preference-Applied: respond-async to distinguish "the server queued this for async processing as I asked" from "the server processed it synchronously and just happened to return quickly."
• API client libraries building reliable preference-aware logic — SDKs and API clients that want to programmatically branch behavior based on whether a preference was honored (rather than guessing from response shape) rely on this header for a clean, explicit signal.

Common mistakes and gotchas

Assuming its absence means the server doesn't support Prefer at all. A server might support Prefer preferences generally but simply not implement the Preference-Applied feedback header — the client can't reliably distinguish "preference was ignored" from "preference was honored, but the server doesn't bother confirming it" without additional context (like actually inspecting the response body/shape).

Servers listing preferences that weren't fully honored. If a server only partially applies a preference (say, it processes asynchronously but ignores the requested wait duration), being precise about exactly what was applied avoids misleading clients that check this header and assume complete compliance.

Client code that doesn't check this header at all. If your client sends Prefer but never inspects Preference-Applied (or otherwise verifies the outcome), you're sending a preference and blindly hoping — somewhat defeating the purpose of having a machine-checkable confirmation mechanism in the first place.

Real-world examples

Confirming a minimal response preference was applied:

POST /api/items HTTP/1.1
Prefer: return=minimal

HTTP/1.1 201 Created
Preference-Applied: return=minimal

Confirming async processing, while wait was not honored (server chose full async instead):

POST /api/exports HTTP/1.1
Prefer: respond-async, wait=5

HTTP/1.1 202 Accepted
Preference-Applied: respond-async
Location: /api/exports/status/xyz789

(The absence of wait=5 in the response signals the server didn't attempt to wait synchronously — it went straight to async.)

FAQ

If Preference-Applied is missing, does that mean my preference was ignored?

Not necessarily with certainty — it could also mean the server doesn't implement this specific confirmation header even though it does support and honor the underlying preference. Checking the actual response shape/behavior alongside this header gives a more complete picture.

Do I need to implement Preference-Applied if I support Prefer server-side?

It's not strictly mandatory, but it's good practice — without it, clients have no standardized way to confirm their preferences were actually honored, which undermines the reliability of using Prefer at all in client-side logic that branches on the outcome.

Can a server list a preference in Preference-Applied that it only partially honored?

This isn't well-defined by spec and is a potential source of ambiguity — best practice is to only list preferences that were fully honored, and be conservative about claiming partial compliance as full application of a preference.

Is this header commonly implemented across APIs that support Prefer?

Implementation consistency varies — some ecosystems (particularly OData-based APIs) have strong conventions around it, while general-purpose REST APIs that support Prefer sometimes skip the confirmation header even while genuinely honoring the preferences themselves.

Fun fact

Preference-Applied exists specifically because HTTP has historically been bad at giving clients explicit confirmation of "soft" server behavior — most confirmation happens implicitly through response status codes and body shape, which works fine for hard requirements but breaks down for genuinely optional processing hints. It's a relatively rare example of a header whose entire purpose is meta-communication about another header's outcome, rather than carrying any content or directive of its own.