201 Created 2xx

What does 201 mean?

A 201 Created response means the request succeeded and resulted in one or more new resources being created. It's a more specific version of 200 — where 200 simply says "this worked," 201 says "this worked, and specifically, something new now exists that didn't before."

201 is most commonly seen as the response to a POST request that creates a new record — a new user account, a new blog post, a new order. The response typically includes a representation of the newly created resource and, ideally, a Location header pointing to where that resource can now be accessed.

How a 201 behaves

• It should include a Location header pointing to the URL of the newly created resource — this lets the client immediately know where to find/access the thing it just created, without needing to search for it
• The response body typically contains the created resource — including any server-generated fields the client wouldn't have known beforehand, like an ID, timestamps, or default values
• It's not cacheable in the traditional sense — a "create" operation is a one-time event, and the response represents that specific creation, not a reusable representation of a general resource state
• It implies the operation is not safe/idempotent — unlike a 200 on a GET, a 201 confirms something was created, and repeating the exact same request might create another new resource (a duplicate) unless the API has specific idempotency handling

Common scenarios

If you're building an API:

• A POST to a "create" endpoint (e.g., POST /users, POST /orders) that successfully creates a new record should return 201, with the new resource's data in the body and a Location header pointing to GET /users/{id} (or similar) for the newly created resource
• Returning 200 instead of 201 for creation endpoints is common but less precise — 201 gives API consumers a clearer, status-code-level signal that "something new was made" without needing to inspect the response body

If you're calling an API:

• A 201 response confirms creation succeeded — check the Location header and/or response body for the new resource's identifier, which you'll typically need for subsequent requests (updating, fetching, or deleting that specific resource)
• Be cautious about retrying a request that previously returned 201 — if the operation isn't idempotent, a retry could create a second resource rather than confirming the first one again

If you're a website visitor:

• 201 is primarily an API-level concept; as a visitor using a website's UI, a successful "create" action (submitting a form to add an item, post a comment, etc.) might trigger a 201 behind the scenes, but you'd typically just see the result reflected in the page rather than the status code itself

200 vs 201 vs 204

Real-world examples

REST APIs that follow conventional design patterns closely (Stripe, GitHub, and many others) return 201 specifically for resource-creation endpoints — creating a new Stripe customer, charge, or subscription via their respective creation endpoints returns 201 with the newly created object's data and ID in the response body, which client libraries then use for subsequent operations on that specific object.

SEO implications

201 is exclusively relevant to API responses for creation operations (POST requests) — it has no direct relevance to page-level SEO, since indexable content is served via GET requests returning 200.

FAQ

What's the difference between 200 and 201?

200 is the general "success" response. 201 specifically indicates that the request resulted in a new resource being created — it's a more precise signal than 200 for creation operations, often accompanied by a Location header pointing to the new resource.

Do all "create" endpoints need to return 201?

It's considered best practice for REST APIs, but not universally enforced — some APIs return 200 for creation operations too. Using 201 specifically is valued because it gives API consumers (and any automated tooling) a status-code-level signal that something new exists, without needing to parse the response body to determine this.

What should the Location header on a 201 response point to?

It should point to the URL where the newly created resource can be retrieved — typically something like /resource-type/{new-id}, allowing the client to immediately fetch, update, or reference the resource it just created using a standard GET request to that URL.

Is a 201 response idempotent?

The response itself doesn't have a "repeat this safely" guarantee the way a GET's 200 does. If the same creation request is sent again, whether it creates a duplicate resource or recognizes the request as already-processed depends entirely on whether the API implements idempotency (e.g., via idempotency keys) — this isn't guaranteed by the 201 status code itself.

Can a single request that creates multiple resources return 201?

Yes — 201 doesn't specify how many resources were created, just that at least one new resource now exists as a result of the request. For bulk-creation endpoints, the response body typically lists all created resources, though the Location header (which points to a single URL) is less straightforward to use meaningfully in this case.

Fun fact

201 is part of a small group of status codes (along with 202, 204, 205, 206) that exist specifically to add nuance to "success" beyond the generic 200 — collectively, they let an API communicate not just that something worked, but what kind of thing happened as a result, which becomes increasingly valuable as API consumers build more automated, status-code-driven logic rather than parsing response bodies for every decision.