# Error handling This section's [checklist items](#integration-checklist) and [standards](#integration-standards) cover logging requests, responses, and errors. This helps ensure you can provide adequate technical details when seeking support from Digital River or upstream platforms. We also cover the types of error messages you should and should not display to your customers. ## Integration checklist Click any checklist item to se more detail on how to meet the integration standard. * [ ] [Depending on the capabilities of your commerce system, do you log all appropriate API requests and responses?](#log-appropriate-api-requests-and-responses) * [ ] [Do you provide a framework for passing failure responses (in other words, non-200 responses) back to your commerce system so that they can be acted upon?](#pass-failure-responses-to-your-commerce-system) * [ ] [Do you display simple but meaningful messages so that customers can effectively respond to the error?](/digital-river-api/general-resources/standards-and-certifications/integration-checklists/error-handling.md#display-errors-to-customers) ## Integration standards These integration standards relate to error handling and logging: ### Log appropriate API requests and responses Logging all of your platform's successful and failed API calls is good practice, especially during the development and testing phases. However, when you're making a large number of calls, this can quickly become overwhelming. You may decide to add a toggle to your tool that allows you to enable or disable debug logging. This would permit each client site to implement the tool to turn off logging when necessary. ### Pass failure responses to your commerce system All the Digital River APIs respond with [standardized HTTP status codes](https://docs.digitalriver.com/digital-river-api-reference#response-status-codes). In case they are needed for support purposes, your platform should log the error responses in the `4xx` and `5xx` range. We recommend you do this regardless of whether you have a setting to disable bug logging. Your error logs should include a timestamp, HTTP code, the URL of the API, and the API request and response payloads. ### Display errors to customers When customers [encounter errors](https://www.digitalriver.com/docs/digital-river-api-reference/#section/Response-status-codes/Error-types) during the checkout process or while interacting with your tool, you should provide them with simple but meaningful messages. You should not, however, share [specific error codes](https://www.digitalriver.com/docs/digital-river-api-reference/#section/Response-status-codes/Error-codes). Doing so increases the probability that attempts to commit fraud and other malicious attacks will eventually succeed. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.digitalriver.com/digital-river-api/general-resources/standards-and-certifications/integration-checklists/error-handling.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.