Success and Error Codes


Each Product Catalog API returns an HTTP status code that indicates the result of the operation. An HTTP status code indicates the outcome of a request, specifying whether it was successfully processed or if an error occurred that requires further handling. Below is a summary of the standard success and error codes.

Standard Success Responses

HTTP Status CodeSuccess TypeDefinition
200OKThe request was successful, and the server returned the expected response.
201CreatedThe request was successful, and a new resource was created.
202AcceptedThe request has been accepted for processing, but processing is not complete.

Standard Error Response

HTTP Status CodeError TypeDefinition
400Bad RequestThe request is malformed or fails request validation (for example, missing required query params, invalid JSON).
401UnauthorizedThe request lacks valid credentials, such as an API Key or Access Token.
403ForbiddenThe request has been authenticated but not authorized. This could be due to insufficient permission to access the API resource.
404Not FoundNo matching resource/method exists.
405Method Not AllowedThe HTTP method is not supported on the resource.
413Payload Too LargeThe request body exceeds the maximum size of 10 MB for REST APIs.
415Unsupported Media TypeIndicates that the Content-Type is not acceptable or is missing.
422Unprocessable EntityThe request is well-formed but has semantic errors (for example, validation failures).
429Too Many RequestsThe rate limit has been exceeded (throttling set on usage plan).
500Internal Server ErrorSomething went wrong in API Gateway itself, or the integration backend returned an unexpected result.
502Bad GatewayThe integration backend failed or returned a malformed response.
503Service UnavailableThe downstream system is unavailable or a timeout occurred.
504Gateway TimeoutNo response was received from the backend within the timeout period (default is 29 seconds).

Recommendations for API Consumers

  • Always check for the correct HTTP status code in your application logic .
  • Gracefully handle error scenarios (for example, 400, 401, 403, 404, 422) by providing clear feedback to the user of your system.
  • Implement retry logic for transient errors like 502, 503, and 504.
  • Use the response body (where applicable) to extract more context or error details provided by the API.