HTTP status codes

HTTP status codes are defined by the IETF in RFC 9110 and registered with IANA. Alibaba Cloud OpenAPI generally follows this standard.

Status code conventions in Alibaba Cloud OpenAPI

Alibaba Cloud OpenAPI generally follows the HTTP status code standard described in this topic: 2xx signals a successful call, 4xx signals a caller-side problem such as an invalid parameter, an authentication failure, insufficient permissions, or an exceeded quota, and 5xx signals a server-side problem. Failed calls usually also return Code and Message fields for finer-grained diagnostics, along with a RequestId that uniquely identifies the call.

Note

The exact semantics and trigger conditions of a status code may vary by cloud service. When you call an OpenAPI operation, refer to the current API reference of that service.

Structure and classes

A status code is a three-digit integer that describes the result of a request and the semantics of the response. Valid values range from 100 to 599. The first digit defines the class of the response; the last two digits carry no categorization role.

Class	Meaning
1xx (Informational)	The request was received and processing continues. These are interim responses: a single request may yield zero or more 1xx responses before exactly one final response.
2xx (Successful)	The request was successfully received, understood, and accepted.
3xx (Redirection)	Further action by the client is required to complete the request.
4xx (Client Error)	The request has bad syntax or cannot be fulfilled. The fault usually lies with the caller.
5xx (Server Error)	The server failed to fulfill an apparently valid request. The fault lies with the server.

Registered status codes

The following tables list the standard meaning of each code and the specification that defines it.

1xx informational

A 1xx response terminates at the end of the header section and cannot carry content or trailers. Because HTTP/1.0 defined no 1xx codes, a server must not send a 1xx response to an HTTP/1.0 client.

Code	Standard name	Meaning	Defined in
100	Continue	The initial part of the request was received and not yet rejected, and the server is willing to accept the request content. Continue sending the body and discard this interim response.	RFC 9110
101	Switching Protocols	The server accepts the protocol change requested through the Upgrade header, and names the protocols that take effect in its own Upgrade header.	RFC 9110
102	Processing	Defined by the WebDAV extension and now deprecated. Avoid it in new designs.	RFC 2518
103	Early Hints	Returns selected headers, typically Link, ahead of the final response so that the client can start preloading resources.	RFC 8297

2xx successful

Code	Standard name	Meaning	Defined in
200	OK	The request succeeded. The response content depends on the method: GET returns a representation of the target resource, POST returns the status or results of the action, PUT and DELETE return the status of the action, and OPTIONS returns communication options.	RFC 9110
201	Created	The request was fulfilled and one or more new resources were created. The primary resource is identified by the Location header, or by the target URI when no Location header is sent.	RFC 9110
202	Accepted	The request was accepted for processing, but processing is incomplete and may ultimately be disallowed. HTTP has no facility for resending a status code from an asynchronous operation, so the response typically points to a status resource that can be polled.	RFC 9110
203	Non-Authoritative Information	The request succeeded, but a transforming proxy modified the content, so it differs from what the origin server would have returned in a 200 response.	RFC 9110
204	No Content	The request was fulfilled and there is no additional content to send in the response body. Metadata can still travel in the response headers.	RFC 9110
205	Reset Content	The request was fulfilled and the client should reset the document view that caused the request, for example by clearing a form.	RFC 9110
206	Partial Content	The server fulfilled a range request and returned one or more parts of the target resource. Common in resumable transfers and chunked downloads of large files.	RFC 9110
207	Multi-Status	Defined by the WebDAV extension. The body carries a separate status for each sub-operation.	RFC 4918
208	Already Reported	Defined by the WebDAV binding extension. Avoids enumerating the same resource repeatedly within one response.	RFC 5842
226	IM Used	The server applied one or more delta encodings to the target resource and returned the delta rather than the full resource.	RFC 3229

3xx redirection

Codes 301, 302, 307, and 308 all place the resource at another URI. They differ in whether the move is permanent and whether the request method may change. For historical reasons, clients handling 301 and 302 may rewrite POST as GET. Use 308 and 307 instead when the method must be preserved.

Code	Standard name	Meaning	Defined in
300	Multiple Choices	The target resource has more than one representation, and the client or the user must choose among them.	RFC 9110
301	Moved Permanently	The target resource was assigned a new permanent URI, and future references should use it. The server should send the new URI in the Location header.	RFC 9110
302	Found	The target resource resides temporarily at a different URI. Because the redirection may change, keep using the original URI for future requests.	RFC 9110
303	See Other	The server redirects the client to another resource to answer the request indirectly. Issue a GET or HEAD request against the URI in the Location header and present that result as the answer. The new URI is not equivalent to the target URI.	RFC 9110
304	Not Modified	A precondition on a conditional GET or HEAD evaluated to false, which means the client already holds a valid representation. The server skips retransmission, and the client can use its cached copy. The response cannot carry content.	RFC 9110
305	Use Proxy	Deprecated. Do not use in new implementations.	RFC 9110
306	(Unused)	Defined in an earlier version of the specification, no longer used, and reserved.	RFC 9110
307	Temporary Redirect	The target resource resides temporarily at a different URI, and the client must not change the request method when following the redirect automatically.	RFC 9110
308	Permanent Redirect	Carries the same semantics as 301 but requires the client to preserve the request method. Defined in 2014, later than its sibling codes, so some legacy implementations may not recognize it.	RFC 9110

4xx client error

Except when responding to HEAD, the server should explain the error in the response body and indicate whether the condition is temporary or permanent. These codes apply to any request method.

Code	Standard name	Meaning	Defined in
400	Bad Request	The server will not process the request because of a perceived client error, such as malformed syntax, invalid message framing, or deceptive routing.	RFC 9110
401	Unauthorized	The request lacks valid authentication credentials for the target resource. The server must send a WWW-Authenticate header naming an applicable challenge. If credentials were supplied, they were refused.	RFC 9110
402	Payment Required	Reserved for future use.	RFC 9110
403	Forbidden	The server understood the request but refuses to fulfill it. If credentials were supplied, the server considers them insufficient, and the client should not retry automatically with the same credentials.	RFC 9110
404	Not Found	The origin server found no current representation of the target resource, or is unwilling to disclose that one exists.	RFC 9110
405	Method Not Allowed	The target resource does not support the request method. The server must send an Allow header listing the supported methods.	RFC 9110
406	Not Acceptable	The target resource has no representation that satisfies the content negotiation headers in the request.	RFC 9110
407	Proxy Authentication Required	Similar to 401, but the client must authenticate with the proxy rather than the origin server.	RFC 9110
408	Request Timeout	The server did not receive a complete request within the time it was prepared to wait.	RFC 9110
409	Conflict	The request conflicts with the current state of the target resource.	RFC 9110
410	Gone	The target resource is no longer available at the origin server, and the condition is likely permanent.	RFC 9110
411	Length Required	The server requires a Content-Length header on the request.	RFC 9110
412	Precondition Failed	One or more preconditions in the request headers evaluated to false on the server.	RFC 9110
413	Content Too Large	The request body is larger than the server is willing or able to process.	RFC 9110
414	URI Too Long	The request target URI is longer than the server is willing to interpret.	RFC 9110
415	Unsupported Media Type	The target resource does not support the content format of the request body.	RFC 9110
416	Range Not Satisfiable	The ranges in the Range header do not overlap the current extent of the resource, or the range set is otherwise invalid.	RFC 9110
417	Expectation Failed	The expectation in the Expect header could not be met by the server.	RFC 9110
418	(Unused)	Previously used by an informal protocol draft. Reserved, and no new semantics may be assigned to it.	RFC 9110
421	Misdirected Request	The request was directed at a server that cannot produce an authoritative response for the target URI.	RFC 9110
422	Unprocessable Content	The media type and syntax of the request body were understood, but the semantic instructions it contains cannot be processed.	RFC 9110
423	Locked	Defined by the WebDAV extension. The target resource is locked.	RFC 4918
424	Failed Dependency	Defined by the WebDAV extension. An action this request depends on did not succeed.	RFC 4918
425	Too Early	The server is unwilling to process a request replayed in TLS early data. Retry after the handshake completes.	RFC 8470
426	Upgrade Required	The server refuses the request over the current protocol but may accept it after the client upgrades. The response must include an Upgrade header.	RFC 9110
428	Precondition Required	The server requires the request to be conditional, which prevents concurrent updates from overwriting each other.	RFC 6585
429	Too Many Requests	The client sent more requests than the rate limit allows in a given period. The response may carry a Retry-After header with the suggested wait time.	RFC 6585
431	Request Header Fields Too Large	An individual header field, or the header section as a whole, exceeds the size the server will process.	RFC 6585
451	Unavailable For Legal Reasons	The server denies access to the resource in response to a legal demand.	RFC 7725

5xx server error

Code	Standard name	Meaning	Defined in
500	Internal Server Error	The server encountered an unexpected condition that prevented it from fulfilling the request.	RFC 9110
501	Not Implemented	The server does not support the functionality required to fulfill the request, typically because it does not recognize the method.	RFC 9110
502	Bad Gateway	A server acting as a gateway or proxy received an invalid response from an upstream server.	RFC 9110
503	Service Unavailable	The server cannot handle the request because of temporary overload or scheduled maintenance. The condition is transient, and the response may carry a Retry-After header.	RFC 9110
504	Gateway Timeout	A server acting as a gateway or proxy did not receive a timely response from an upstream server.	RFC 9110
505	HTTP Version Not Supported	The server does not support, or refuses to support, the major HTTP version used in the request.	RFC 9110
506	Variant Also Negotiates	Defined by the transparent content negotiation extension. Indicates an internal configuration error on the server.	RFC 2295
507	Insufficient Storage	Defined by the WebDAV extension. The server cannot allocate enough storage to complete the request.	RFC 4918
508	Loop Detected	Defined by the WebDAV binding extension. The server detected an infinite loop while processing the request.	RFC 5842
510	Not Extended	The original definition was obsoleted. The code remains registered, but its semantics no longer apply.	RFC 2774
511	Network Authentication Required	The client must authenticate to gain network access, as with the captive portal of a public Wi-Fi network.	RFC 6585