​

API analytics dashboards (read-only)

The Developer → API analytics page in the dashboard is the read-only counterpart of the API governance console: it shows what your API traffic is doing right now without putting limits or keys at risk. Because analytics reads are safe for the viewer role, hand this page to the people who monitor usage — and keep the governance console where limits are set to owner, admin, or developer. You need the owner, admin, developer, or viewer role. The same four roles gate the underlying API (/api/v1/developers/api-analytics), so anyone who can open the page sees exactly the same data from a script.

​

What this page reports

Six widgets read from the same timeframe selector at the top of the page — Last 24 hours, Last 7 days, or Last 30 days:

• Headline KPIs — total requests, the API-key request share of that traffic, the API-key error rate, and p50/p95 latency. When a workspace drives Orbit only from the dashboard (no API-key traffic), the error-rate and latency tiles show an explicit unavailable placeholder instead of a fabricated zero.
• Request volume — an hourly (24h window) or daily (7d/30d windows) timeseries, with the peak bucket labeled per its period so a 7d peak never reads as an hourly figure.
• Rate-limit usage — which endpoints and keys were rejected with 429 inside the window, so a governance change you just saved shows its effect here.
• Messaging usage — per-channel message volume, delivery, and spend for the same window (a separate axis from API-request metrics).
• Latency-spike alerts — each endpoint’s p95 is compared against your other endpoints in the window; an endpoint more than two standard deviations above the cohort gets an alert card. Low-traffic endpoints (under 10 requests in the window) are never flagged, and the top three cards show with a +N more toggle.
• Breakdown tables — a By endpoint tab (per-endpoint count, errors, p50/p95) and a By API key tab (per-key today / 7d / 30d counts, 30-day error count, last-used timestamp and IP).

The selector choice, table sort, key-sort, and revoked-keys toggle all live in the page URL, so a deep link captures the exact view — browser back/forward walks filter combinations and a screenshot URL is self-describing.

​

Drill from an alert down to the requests

Each latency-spike card carries two destinations, because a highlight in a summary table is not a diagnosis:

1. View endpoint — flips the By endpoint tab forward, sorts it by latency, scrolls to and highlights the offending row, and opens a diagnostics drawer restating the alert against that endpoint’s full count/error/latency metrics.
2. View request logs — opens Developer → Request logs pre-filtered to the endpoint’s method and path prefix, so you are looking at the individual slow or failing requests, their status codes, and bodies — the actual diagnosis surface.

Close the diagnostics drawer and the in-page highlight stays, so you can pause on either step.

​

Per-key attribution and export

The By API key tab pivots the same metrics onto the key axis — open it when you want to know which integration is driving the window’s traffic, not just which endpoint. Sort by 30-day, 7-day, or today’s count, or by last-used time; toggle Include revoked if the traffic you are chasing came from a since-revoked key. Use Export CSV on that tab to download the rows — the file is timestamped and values are quoted so they round-trip into a spreadsheet without mangling. Above the tables, the Ask Orbit box answers a plain-English question (“which endpoints error the most this week?”, “what’s my p95 today?”) from the same telemetry, so a viewer who would rather ask than scan still gets a grounded number.

​

When to open the governance console instead

This page never changes a limit — when the rate-limit panel or a headline number tells you the ceiling itself is wrong, that is a governance decision. Open the API rate limits & quotas console to raise a per-key override or the org-wide default; the analytics page then becomes the place you confirm the change took effect.