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
429inside 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).
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:- 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.
- 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.
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.Read the same data from a script
The same four roles that open this page — owner, admin, developer, viewer — gate the read API behind it, so any key carrying one of them can pull the exact widgets above into your own tooling (Grafana, a Cronicle job, a cron-dumped CSV). Authenticate withX-API-Key, just like any other Orbit API call; the base URL is https://api.orbit.devotel.io/api/v1 and its endpoints live under developers/api-analytics. Every response comes back in the standard Orbit envelope — the payload under data, a meta.request_id / meta.timestamp block beside it.
All reads accept a window query param of 24h, 7d, or 30d (30 days is the oldest data Orbit meters — nothing older than 30 days ever enters these aggregates).
Headline KPIs
error_rate is a percentage (0–100) scoped to your API-key traffic; total_requests and error_count are all-traffic volume counts. Three fields are deliberately nullable: error_rate, p50_latency_ms, and p95_latency_ms come back null — never 0 — when the window held no API-key traffic to measure (a workspace driven only from the dashboard hits exactly this). Render an explicit unavailable placeholder for null; do not coerce it to zero or you will print a confident “0.00%” / “0 ms” next to a non-zero error_count.
Drill into a latency spike (By endpoint)
sort accepts count, errors, or latency, and limit accepts up to 100 rows. Once the row tells you the method and path_pattern, open Developer → Request logs filtered to the same pair for the individual slow or failing requests, exactly as the in-page drill does.
Attribute traffic per API key
window you pass; cost_month_minor is the key’s current-month spend in integer cents (read 12844 as $128.44) and null on the __none__ session bucket and __deleted__:<suffix> sentinel rows, whose per-request spend is unattributable. total_keys reports the bucket count before your limit clips the page, so rows.length < total_keys tells you to page further. Compare last_used_at and last_used_ip across keys to find which integration is driving the window — and pass includeRevoked=true when the traffic you are chasing came from a since-revoked key.
Chart the volume (timeseries)
groupBy=hour|day only if you want to override the resolution. The series is gap-filled — every hour/day in the window arrives with an explicit zero — so you can hand the array straight to a charting library, and the peak bucket inherits the same resolution the echo’d groupBy reports. Daily buckets are cut at your workspace’s wall-clock midnight, not UTC.
Ask a plain-English question
data carries the full snapshot so you can chart it without a second call. understood: false means no metric keyword was recognised and the answer fell back to the request-volume default — surface that guess to your users rather than treating the answer as definitive.
All six reads are tenant-scoped and cached for 60 seconds, so repeating a call inside that window returns the same numbers; hit them on a one-minute cadence and you mirror the dashboard’s own polling.
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.