Logs for data exchange

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:

• Connection
• Configuration
• Date range
• Data model
• Event type
• Log type
• Status

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: SEND, RECEIVE, REQUEST, or RESPOND. The log type describes:

• the event type, either asynchronous (SEND/RECEIVE) or synchronous (REQUEST/RESPOND), and
• the originating system for the request, whether yours or your connection’s.

We create a log for every attempted request.

A log with type SEND or 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. 

1. Parallel processing: Redox sometimes processes requests in parallel, and errors can occur while trying to process multiple requests. If this happens, your queue of asynchronous requests is paused until Redox resolves the issue. You can manually retry sending the request (learn how to initiate a retry), but Redox also monitors paused queues to resolve issues. If the manual retry isn’t successful or you need more immediate support from us, submit a ticket via our Help Desk. 
2. Failed delivery: Other times, Redox successfully processes your request, but the endpoint doesn’t accept it when we attempt delivery. This would be like if a mail carrier gets your package to the right address with the right contents, but the recipient doesn’t ever open the door. We automatically retry sending in this case, but you can also manually retry sending the request. 

Learn more about how we handle automatic and manual retries for asynchronous requests.

A log with type REQUEST or 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:

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.