Analytics & Monitoring

The Developers page inside the Trust Management Platform gives you a real-time view of how your API integration is performing. You can track request volume, inspect failure rates by endpoint, filter down to individual HTTP status codes, and search the full request log — all without touching a log file.

This guide walks through every part of the analytics dashboard and explains how to use each tool effectively.

---

Accessing the Dashboard

Navigate to Developers in the platform sidebar. You need the View API Analytics permission assigned to your account. If you see a "no permission" message, contact your organisation administrator.

If you're an operations administrator managing multiple clients, use the client selector in the header to switch context before viewing analytics. Each client's data is isolated.

---

Time Range

Both tabs share a single time range selector displayed alongside the tab bar:

Switching the range immediately refreshes both Overview and Monitoring data for the selected window.

---

Overview Tab

The Overview tab gives you a high-level health summary of your API activity.

Summary Cards

Four metric cards appear at the top:

• Total requests — all requests made by your API credentials in the selected range
• Successful requests — requests that returned a 2xx status code, with the percentage of total shown below the count
• Failed requests — requests that returned a 4xx or 5xx status code, with the failure percentage
• Avg response time — mean server processing time in milliseconds across all requests

The success and failure percentages use your total request count as the denominator, so they always add up to 100%.

Request Volume Chart

The bar chart breaks down requests by day (or hour for the 24h range). Each bar is split into two segments:

• Green — successful requests (2xx)
• Red — failed requests (4xx / 5xx)

Use the Success and Errors toggles above the chart to isolate either series. The "By category" legend on the right shows request volume grouped by API category (e.g., Accounts, Transactions, Whitelisted Addresses).

Tip: A sudden spike in the red segment on a specific day is a quick signal to cross-reference with a deployment or config change on that date.

Response Codes

The donut chart shows the distribution of individual HTTP status codes across all requests in the range. Each distinct status code gets its own colour within its family:

Hover over any slice to see the exact count and share of total for that status code.

The legend to the right lists every status code present in your data with its raw count. If you see a large share of 401 or 403 responses, verify that your API credentials have the correct permission scopes assigned.

Top Endpoints

The top-endpoints panel ranks your highest-volume API paths. Each row shows:

• The HTTP method badge (colour-coded: GET = blue, POST = green, PUT/PATCH = amber, DELETE = red)
• The endpoint path
• A progress bar that fills to 100% — the green portion represents the success rate for that specific endpoint, and the red portion represents its failure rate
• The total request count and failed count

Hover any row to open a tooltip with the full success/failure breakdown.

If a single endpoint has a high failure rate compared to others, it's a useful starting point for debugging — check that endpoint's required permissions and payload format.

Recent Failed Requests

The table at the bottom of the Overview tab shows the most recent 4xx and 5xx responses. Each row includes:

• Timestamp — when the failure occurred
• Endpoint — the path that was called
• Method — GET, POST, PUT, PATCH, or DELETE
• Status code — the HTTP response code returned
• Reason — a short error description when available
• API user — which of your API credentials made the call

Use this table to quickly identify whether failures are concentrated on a specific credential, a specific path, or a particular error type.

---

Monitoring Tab

The Monitoring tab is designed for deeper inspection — it gives you a filterable, searchable view of every request bucket in the selected range.

Requests Over Time (Line Chart)

The line chart plots request counts over time, with one line per HTTP status code present in your data. Each status code is rendered in a distinct colour within its family, so you can visually separate 200 from 201, or 404 from 429, on the same chart.

The chart respects any filters you apply in the sidebar — deselecting a status code removes its line immediately.

Filter Sidebar

On mobile, tap Show filters to expand the sidebar. On desktop it is always visible on the left.

Three filter groups are available:

Response codes — expand each family (2XX, 4XX, 5XX) to toggle individual status codes. The family-level checkbox is indeterminate when only some codes in that family are selected. Use this to isolate, for example, only 429 Too Many Requests responses to investigate rate-limit behaviour.

Methods — toggle any combination of GET, POST, PUT, PATCH, DELETE. Useful when you want to look at only write operations (POST/PUT/PATCH/DELETE) or only read operations (GET).

Categories — filter by API category. Categories match the top-level groupings in the API (Accounts, Transactions, Whitelisted Addresses, and more). Available categories depend on which endpoints were called in the selected window.

Click Reset at the top of the sidebar to clear all filters and return to the full dataset.

Request Log Table

The table below the chart shows every request bucket that matches your current filters. Columns:

Use the Search endpoint box to filter rows by path or category name. The search is case-insensitive and matches substrings, so typing /accounts will surface all account-related paths.

The table loads 50 rows at a time and automatically fetches more as you scroll down.

---

Common Workflows

Diagnosing a Spike in Failures

1. Go to Overview and look at the Request Volume chart for the affected day.
2. Check the Response Codes donut — is the spike concentrated in 4xx (client errors) or 5xx (server errors)?
3. Open Recent Failed Requests and note which endpoints and API credentials appear most frequently.
4. Switch to Monitoring, set the time range to 24h, and use the Response codes filter to isolate the failing status code.
5. Search the endpoint path in the Request Log to see which time buckets had the highest count.

Verifying a New Integration

After going live with a new API credential:

1. Make a few test requests through your integration.
2. Open Monitoring and set the range to 24h.
3. Filter by Method: POST (or whichever method your integration uses) to isolate your activity.
4. Confirm the Requests over time chart shows green (2xx) lines and the Request Log contains your expected endpoints.

Investigating Rate Limit Errors

If your integration is hitting 429 Too Many Requests:

1. In Monitoring, expand the 4XX family in the Response codes filter and select only 429.
2. Check the Requests over time chart for the pattern — is the rate limiting consistent, or does it spike at specific times?
3. Use the Methods filter to narrow down whether the 429s are on read or write operations.
4. Reduce request frequency or implement exponential back-off in your client to stay within the rate limit window.

---

Understanding the Data

• Bucket granularity: The 24h range shows per-hour counts; 7d and 30d show per-day counts. A "0" in a time bucket means no requests were made in that window — it does not mean data is missing.
• Client scoping: All data shown is scoped exclusively to your client. If you are an admin managing multiple clients, switching clients in the header will refresh all charts.
• Latency: Analytics data is typically available within a few minutes of requests being made.

---

Getting Help

If you notice persistent errors or unexpected data:

• Check the Recent Failed Requests table for error reasons.
• Verify your API credential's permission scopes in Settings → API Credentials.
• Review the Authorization guide to confirm your request headers are formed correctly.
• Contact support if you see 5xx errors that are not explained by your integration.