Let's say that you are exposing an API on an API Gateway that in turn calls out to SalesForce APIs. If your own API is running slowly, you need to be able to isolate the reason. Here, in the web interface to the API Server, I am looking at the transaction and I see two call-outs to SalesForce APIs. The second one, to the SalesForce log-in service, is taking a long time (see the timings circled in red below).
We see at a glance each input and output message being sent to the API, and we can also look at the request and the response to the client calling the API at the API Server. This allows you to pinpoint the cause of any delay and see message timings at a fine-grained level.
You can then go one step further. If you click on the Filter Execution section and expand it, you can see exactly the timing of each step in the API Server. I've highlighted the step where we call out to SalesForce to log in to SalesForce. We can see that that step is taking a long time, whereas other steps within the API Server are very fast.
We've tried to make it very simple to see not only how long a transaction takes but also how long each step in the transaction takes. So if a client says "my API calls are too slow!" you can look at the API Server's web interface and see the reason at a glance. Then, you can take action (e.g. enable distributed caching, or add proactive load-balancing across multiple APIs).