Error Management
General error management
Last updated
Was this helpful?
General error management
Last updated
Was this helpful?
Error Handling
XCover uses conventional HTTP response codes to indicate the success or failure of an API request. Error codes ranging from 400 to 499 represent various error codes. Errors that can be resolved programmatically will result in an error code that briefly explains the type of error or reason for the error. In the unlikely event of a 5xx error, our engineering team will automatically receive a report and will fix any issue as fast as possible.
Note the below workflow for error handling:
XCover strongly recommends the following mechanisms for error handling:
Retry Mechanism
The request/response goes through various hops between Partners and XCover. These may include various networks and servers. If at any point, the request fails due to network issue for example (e.g. a timeout), Partners should try to resend the request at least twice to rule out any intermittent issue. For Asynchronous request situations, retries may be spaced comfortably, ideally 2-5 mins apart before sending out an alert for someone to manually check any issues. We recommend at least 5 second timeout for bookings, and setting it to 10 seconds or more should be more reliable and not be a problem for customers. If requests fail, they should be retried with exponential backoff. In case the booking creation failed 5 times, partners should flag and raise with Cover Genius. Similar logic should apply for cancellations.
Alert Mechanism
If, after the second try Partners fail to receive the expected response (received, confirmed etc), it is recommended to establish alert mechanisms that notify responsible teams of the failure.
Logging Mechanism
Irrespective of a correct or a failed request/response, it is highly recommended for Partners to log requests and responses all centrally. These assist investigation where besides direct issue itself, patterns may become visible, helping to identify overarching issues.
