Logs show the data exchanged with your integrations via Redox. Specifically, a log is an aggregation of small transactional components that contain the data payload or request sent from one system to another. Data can be exchanged asynchronously or synchronously. Learn about the difference between asynchronous and synchronous.
On the Redox dashboard, you can navigate to the Logs page to view or search logs using these filters:
Resulting logs are sorted by timestamp with the most recent log at the top.
By default, your Logs page is empty until you start using DevTools (located on the Developer page). The Logs page becomes populated once you start sending and receiving requests.
Dashboard logs include the body of your API requests, so PHI may be included. PHI information is only visible to users with PHI access. If a user without PHI access tries to view a log with PHI, the metadata is visible but the content isn't. Learn more about user management and permissions.
There are four log types:
RESPOND. The log type describes:
RECEIVE) or synchronous (
Sometimes, an error may occur during initial processing, so we can’t determine the log type. In these cases, the log type will be
UNKNOWN. If this happens, you may also not be able to see the available data model, event type, or integration information.
We create a log for every attempted request.
A log with type
RECEIVE describes an asynchronous request. Asynchronous requests can be duplicated and sent to any number of endpoints, depending on how many integrations are in place and how many endpoints are designated within the request. Since a log is created for every attempted request, this means that if one asynchronous request routes to 10 endpoints, it generates 10 log entries.
These types of requests may attempt processing and delivery multiple times before a successful attempt. There are a couple of reasons why an asynchronous request may fail.
We don't send you a notification in the case of a failed delivery. But you can check the log status to see if the request went through successfully.
A log with type
RESPOND describes a synchronous request. In order to translate between both sides of your integration, these types of requests are processed twice: once for the originating request and once for the response.
If either side of the integration fails to process the request, it can’t be retried like an asynchronous request. This is because the request waits for a response.
To use the mail carrier analogy from above, this would be like having a mail carrier deliver a package then wait for the recipient to write back to the sender before leaving the package. Since we don’t want our faithful mail carrier—or Redox—to wait around forever, a synchronous request simply fails if there’s not a response. So if the request fails, a duplicate request needs to be sent to successfully deliver the request and receive the expected response.
Every log has a distinct status that reflects its current or final state:
The request was successfully processed and delivered to the designated endpoint.
The request did not process correctly or could not be delivered to the designated endpoint. For a failed asynchronous request to a production environment, this could also mean that retries have been attempted but were not successful.
The data payload was intentionally filtered based on your filter settings for the related data model.
The request is either a) queued for processing, b) currently processing, or c) queued for or currently attempting a retry.
Of these statuses, PENDING is the only one that represents an interim state; the others are final states and will not change. A pending state is most common for asynchronous requests.
For more details on FILTERED, read about filters.