During development, it can be useful to see exactly how the data in Ravelin came to be. Request logs are a useful tool that can be used to look up all of the requests made to and responses received from the Ravelin API.
Request logs can be searched in a number of ways and can be accessed by clicking the Request Logs tab from the Developer menu in the Dashboard:
Logs are separated into 3 groups, which are explained in greater detail below:
- Entity ID
- Ravelin endpoint
- Bad requests
Searching for logs with Entity IDs is recommended if there is a specific ID that you need further logs on. An example use case for this would be to lookup the history of a particular payment method, across all customers. Other valid Entity ID's are as follows, and can be selected with the required dropdown menu option:
- Payment Method (paymentMethodId)
The entity IDs can be found through the appropriate sections of a customers page.
The Ravelin Endpoint option allow you to review all logs for any endpoints of Ravelin APIs, and can further be broken down by several status codes received from Ravelin: 200, 202, 400, 429, 500. A quick rundown of the status codes can be found below, as well as example use cases.
- 200 (OK): This status code shows all requests that were successful.
- 202 (Accepted): This status code shows all of the requests that were accepted by Ravelin, but that have not yet been fully processed. This most often happens during the backfill process.
- 400 (Bad request): Logs for this status code will show all of the requests that could not be understood by Ravelin. The response body for requests that resulted in 400 status codes provide a brief explanation why this was returned.
- 429 (Too many requests): This shows the requests that breached the rate limits that we have in place. If errors are seen here, please contact our support team for investigation and a further review of your rate limits. If you are performing a backfill, make sure you are using the /v2/backfill/* endpoints.
- 500 (Internal server error): This shows the requests that we could not handle due to issues with the Ravelin service.
Reviewing logs that were classified as bad requests is an invaluable tool both during and after the integration of Ravelin, as the reasons for classification are provided in the response from Ravelin. Any requests found in this section should be investigated further to ensure that we are receiving correct information at all times.
Bad requests and logs that are viewed by request path are saved for 1 month, however entity ID logs are stored forever.