Skip to content

Status Codes

The Petstore API uses standard HTTP status codes to indicate the result of an API request.

Status codes help client applications determine whether a request was completed successfully or if additional action is required due to an error or validation issue.

The API may return different status codes depending on the endpoint, request method, request payload, and server response.

Status Code Categories

HTTP status codes are grouped into different categories based on the response type.

Category Description
2xx Successful request
4xx Client-side error
5xx Server-side error

Commonly Used Status Codes

The following status codes are commonly returned by the Petstore API.

Status Code Description
200 OK The request was processed successfully
201 Created A new resource was created successfully
400 Bad Request The request contains invalid data or parameters
401 Unauthorized Authentication failed or credentials are missing
403 Forbidden Access to the requested resource is restricted
404 Not Found The requested resource does not exist
405 Method Not Allowed The HTTP method is not supported for the endpoint
500 Internal Server Error An unexpected server-side error occurred

Success Responses

Successful requests typically return a 200 OK or 201 Created status code.

Example:

{
  "id": 101,
  "name": "Rocky",
  "status": "available"
}

Client Error Responses

Client-side errors usually occur due to: - invalid request payloads - missing parameters - invalid resource identifiers - authentication failures

Example:

{
  "code": 400,
  "type": "error",
  "message": "Invalid request payload"
}

Server Error Responses

Server-side errors indicate that the request could not be processed due to an issue on the server.

Example:

{
  "code": 500,
  "type": "error",
  "message": "Internal server error"
}

Best Practices

While working with API responses:

  • Always validate the returned status code before processing the response payload.
  • Handle 4xx and 5xx responses appropriately in client applications.
  • Avoid assuming that every request returns a successful response.
  • Log unexpected error responses for troubleshooting and debugging.
  • Implement retry mechanisms carefully for temporary server-side failures.