| Table of Contents |
|---|
...
It is expected that your PMS/CRS/RMS has a robust error handling process as outlined as and agreed to in our 'Best Practices'. This includes a queuing mechanism and a robust retry strategy. More information in relation to Error Handling is outlined below.
...
| Error Code | Error Reason | Suggested Handling Method |
|---|---|---|
| 500 - Internal Server Error | A generic error message, given when an unexpected condition was encountered and no more specific message is suitable. | Please implement a retry strategy that aims to establish whether the 500 error received is a random event. Once established the error is not a random event (using a retry strategy), please verify the request is valid. If you believe the request to be valid, please reach out to our Application Operations team. |
| 501 - Not Implemented | The server either does not recognise the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API). | Please fail request and review whether the request is currently supported by the web service attached to this endpoint. |
| 502 - Bad Gateway | The server was acting as a gateway or proxy and received an invalid response from the upstream server. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
| 503 - Service Unavailable | The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
| 504 - Gateway Timeout | The server was acting as a gateway or proxy and did not receive a timely response from the upstream server. | For this you should implement a retry strategy that is sympathetic to high load situations. We suggest that you implement an 'Exponential Backoff' strategy (see Exponential Backoff). We'd recommend something like: 5 seconds → 10 seconds → 20 seconds → 40 seconds → then every minute until a defined timeout. We recommend at least 30 minutes from the initial request until a timeout is considered. Once the time out is reached and the message has failed, please reach out to our Application Operations team. |
| 505 - HTTP Version Not Supported | The server does not support the HTTP protocol version used in the request. | Please fail the request and ensure that the client making requests to pmsXchange has been configured correctly. |
...