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.

You and your connection can exchange data 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

Redox sorts resulting logs 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 protected health information (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 initiating 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 multiple endpoints. This depends on how many integrations you have and how many endpoints you designate within the request.

Redox creates a log for every attempted request. So if one asynchronous request routes to 10 endpoints, it generates 10 log entries.

Asynchronous requests may attempt processing and delivery multiple times before being successful. There are a couple of reasons 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, Redox pauses your queue of asynchronous requests until we resolve the issue. You can manually retry sending the request (learn how to initiate a retry), but Redox also watches 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. Redox processes these types of requests twice: once for the initiating 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 another mail carrier analogy, 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, you must send a duplicate request 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 won't change. A pending state is most common for asynchronous requests.

For more details on FILTERED, read about filters.