307 Temporary Redirect
The resource temporarily resides at a different URL, and the request method and body must be repeated exactly.
Defined in RFC 9110 §15.4.8
What 307 means
A 307 response is the unambiguous counterpart to 302: it indicates the target resource temporarily resides at the URL given by the Location header, but explicitly requires the client to reuse the same HTTP method and, for methods that carry one, the same request body when following it. RFC 9110 introduced 307 precisely because 302’s historical behavior of silently downgrading POST to GET made it unsafe for redirects that must preserve method semantics.
This matters most for non-idempotent or state-changing requests. If an API needs to redirect a PUT or POST (for example, from an old endpoint to a new one, or from a non-canonical host to a canonical one) without losing the request body, 307 guarantees compliant clients replay the exact method and payload at the new URL. Compare this to 303, which forces a GET regardless of the original method, and to 301/302, whose method-preservation behavior is unreliable across real-world clients.
Because the redirect is declared temporary, browsers and caches should not treat 307 as a permanent instruction the way they might treat 301 or 308; the original URL remains the one to keep requesting going forward. This makes 307 appropriate for short-lived routing decisions, such as failover to a backup origin or maintenance-mode redirection, where the method and payload must survive but the target may well change again.
One practical wrinkle: because 307 replays the body, browsers will typically prompt the user for confirmation before resubmitting a form via 307 if the original request was a POST triggered by user interaction, similar to a page refresh warning. API clients and server-to-server HTTP libraries do not have this UX concern and simply replay the request automatically.
Common causes
- A server needs to redirect a POST, PUT, PATCH, or DELETE request to a new URL without losing the method or body.
- A temporary maintenance window redirects state-changing API calls to a backup or read-replica endpoint.
- An API gateway or load balancer reroutes traffic to a different backend during a rolling deployment.
- A framework’s method-preserving redirect helper is used instead of the default 302 behavior.
- A mobile or IoT client integration requires exact method/body replay that 302 could not reliably guarantee.
How to fix a 307
If you are the client (browser user or API caller)
- Ensure your HTTP client library actually preserves the method and body on 307, since some older or non-compliant clients still mishandle this.
- Expect a possible user confirmation prompt in browsers when a 307 redirect would resubmit a POST from a form.
- Do not cache the redirect target as permanent; keep using the original URL for future requests.
- Verify request bodies with a Content-Length or chunked encoding are correctly replayed, especially for streaming uploads.
If you run the server
- Use 307 (not 302) whenever a temporary redirect must preserve the exact method and request body.
- Set Location to an absolute URL, and ensure the target endpoint can genuinely accept the same method and payload.
- Avoid redirect chains; resolve directly to the final backend rather than bouncing through multiple 307s.
- Reserve 307 for genuinely temporary situations; switch to 308 once the redirect becomes permanent.
Example
PUT /api/v1/orders/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
{ "status": "shipped" }
HTTP/1.1 307 Temporary Redirect
Location: https://api-backup.example.com/api/v1/orders/42
PUT /api/v1/orders/42 HTTP/1.1
Host: api-backup.example.com
Content-Type: application/json
{ "status": "shipped" }Try it live
Our free status responder returns a real HTTP 307 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/307