Is POST idempotent? No, but PUT and DELETE are

No, POST is not idempotent. The HTTP standard, RFC 9110, defines PUT, DELETE and the safe methods GET, HEAD, OPTIONS and TRACE as idempotent: several identical requests have the same intended effect on the server as one. POST asks the server to process what you send by its own rules, such as creating a new record each time, and PATCH isn't idempotent by definition either.

The method definitions are quoted from RFC 9110, RFC 5789 and MDN's Idempotent and Safe glossary pages. The Sume retry behavior comes from its Create a run, Jobs and results and Waiting for runs and jobs docs, plus the current SDK code. All were read on 2026-09-28.

Which HTTP methods are idempotent?

RFC 9110 marks each method it defines as safe or not and idempotent or not. PATCH is defined in RFC 5789, which says it is neither.

Idempotent describes the intended effect on the server, not the response. In MDN's example, the first DELETE of a record will likely return 200 and the repeats 404, yet the record is gone either way. A server may still log every request: RFC 9110 says the property only applies to what the client requested.

What is the difference between safe and idempotent?

A safe method is read-only by definition: the client does not request, and does not expect, any state change on the server. An idempotent method may change state, but repeating it changes nothing more. So every safe method is idempotent, but not every idempotent method is safe. MDN's examples are PUT and DELETE, which are idempotent but unsafe.

The labels let software act on its own. Crawlers and pre-fetching can send safe requests without fear of causing harm, and a client can repeat an idempotent request automatically when the connection fails before it reads the response.

Why is PUT idempotent but POST is not?

They differ in what the body means. A PUT asks the server to create or replace the target resource with the state in the body, so the same body sent twice leaves the same state. A POST asks the target resource to process the body by its own rules, for example creating a new resource the server has yet to name, or appending data. RFC 9110 calls this the fundamental difference between the two: the intent of PUT is idempotent. MDN's counterexample is a POST /add_row that adds another row on every call.

That is also why APIs create things with POST: RFC 9110 says a service that picks the new resource's URI itself should use POST rather than PUT.

Is PATCH idempotent?

Not by definition. RFC 5789 says PATCH is neither safe nor idempotent: its body is a set of instructions for changing a resource, and applying it may even create or modify other resources. A patch that sets a field to a fixed value can be repeated without harm; one that appends to a list or adds to a counter cannot. The RFC notes a PATCH can be issued in such a way as to be idempotent, and tells clients whose patch format needs a known starting version to send a conditional request, such as an If-Match ETag, so a stale patch fails.

How do I retry a POST safely?

Give the server a way to recognize the repeat. RFC 9110 says a client should not automatically retry a non-idempotent request unless it has some means to know the request is actually idempotent, or that the original was never applied. An idempotency key is that means: the client sends a unique key with the POST, and the server answers a repeat of the same key and body with the first result instead of doing the work again.

On Sume, that key is the Idempotency-Key header on a create: the same key with the same body returns 200 with the original receipt, with no second run and no second charge. Idempotency keys for AI video APIs covers how to build the key and every replay outcome.

Sume's TypeScript SDK applies the RFC's rule: in current code it retries a GET or HEAD after a 408, 429, 5xx or transport failure, but a POST only when it carries an Idempotency-Key, since without one a replay would start and bill a second run.

A POST can also be idempotent by design. On Sume, POST /v1/jobs/{id}/cancel on a job that is already canceled returns the same canceled job, as How to cancel an AI video job describes.