HTTP 427 Unassigned
HTTP 427 is an unassigned status code with no official definition in the IANA HTTP status code registry. If you are seeing 427, it is being generated by an application, server, or intermediary using a non-standard or proprietary interpretation. There is no RFC or specification that defines what 427 means.
Quick reference
| Code | 427 |
|---|---|
| Name | Unassigned |
| Category | 4xx Client Errors |
| Specification | IANA Registry (Unassigned) |
| IANA status | Unassigned — no official definition |
| Cacheable | No |
| Client action | Treat as an unrecognized 4xx error. Check server logs for the application-specific meaning. |
| In-depth guide | HTTP 427 full guide → |
What HTTP 427 means
IANA's HTTP status code registry lists 427 as unassigned — no RFC has defined it as a standard code. Despite this, applications and servers sometimes return 427 for proprietary reasons. The meaning depends entirely on the application or infrastructure returning it.
Per RFC 9110, clients that receive an unrecognized 4xx status code should treat it as equivalent to 400 Bad Request — indicating a client-side error condition. The response body should provide more specific information about what went wrong, if the application returning 427 includes an error message.
Unassigned codes in the 4xx range typically appear when: a developer chose an unused code for a proprietary error condition without checking the registry, a non-standard extension from a specific platform or framework uses the code, or a system incorrectly generates a numeric response code due to a bug.
How to handle an unexpected 427
- Read the response body. The application returning 427 likely includes an error message or code in the body that explains the specific condition.
- Check documentation. If you are integrating with an API or platform that returns 427, check their documentation for the specific meaning.
- Treat as a 4xx error. Without more context, handle 427 like 400 — a client-side problem that requires investigation before retrying.
- Check server logs. If you control the server returning 427, check logs for context about when and why the code is generated.
Unassigned codes and RFC 9110
RFC 9110 specifies that HTTP status codes are extensible, and implementations can use unassigned codes. However, the specification also notes that unrecognized codes should be treated as the x00 code of their class — so a 427 should be treated as 400. Using unassigned codes in APIs creates interoperability problems: monitoring tools, client libraries, and intermediaries do not know how to handle them.
If you are building an API and need a custom error response, use a well-known status code (400, 422, 429, etc.) and put the specific error detail in the response body as a structured JSON error object.
FAQ
What does HTTP 427 mean?
HTTP 427 is unassigned with no official definition. The meaning depends on the application returning it. Treat it as a 4xx client error and check the response body for details.
Is 427 an official HTTP status code?
No. IANA lists 427 as unassigned. It has no RFC definition and is not part of the standard HTTP specification.
Should I use 427 in my API?
No. Use a standardized status code instead. Put custom error details in the response body as a structured JSON object. Using unassigned codes creates interoperability problems and confuses clients.
How should a client handle a 427 response?
Treat it as 400 Bad Request per RFC 9110 guidance on unrecognized 4xx codes. Read the response body for application-specific error details.
Related resources
On this site: HTTP 427 — full guide · HTTP 400 Bad Request · HTTP 426 Upgrade Required · HTTP 428 Precondition Required · All 4xx client errors
Standards: IANA HTTP Status Code Registry