Skip to main content

​
Developer hub overview

The Developer hub is the entry point of the dashboard’s developer area — a hub page that lands every integration on the same four numbers before linking out to the deep consoles. The KPI cards at the top aggregate your API-key traffic computed from server-side request metrics, so a healthy hub page is the fastest possible answer to “is my integration behaving?” Open it at Developer (/[locale]/developer in the dashboard); every console the cards summarize — Request logs, API analytics, rate limits & quotas — is one tile away. You need the owner, admin, developer, or viewer role. The same four roles gate the analytics endpoints the cards read, so anyone with the page also reads the same numbers from a script.

​
What the hub counts

Three of the four KPI cards draw from the API analytics overview (the same aggregation that backs Developer → API analytics):
  • API Calls Today — genuine API-key requests made since your workspace’s wall-clock midnight. First-party dashboard browsing (the session polls every logged-in UI emits) is excluded, so the count reflects real programmatic traffic, not idle tab usage.
  • Avg Latency — the arithmetic mean of request duration over the rolling 24-hour window, scoped to API-key traffic. A dashboard-only workspace reads an explicit unavailable placeholder rather than a fabricated zero.
  • Success Rate — the API request success rate: 100 minus the percentage of API-key requests that returned a 4xx or 5xx in the same window. It counts HTTP calls, not message deliveries.
  • Active Keys — the keys on your account not revoked. If the keys fetch itself fails, the page says so inline with a retry instead of reporting zero keys.
Below the cards, the hub tiles link to each deep-dive console: API reference, SDKs, webhook tester, key management, Request logs, API analytics, Rate limits & quotas, sandbox, playground, MCP server, event sinks, and the rest of the developer surface. A three-step quickstart (create a key, install an SDK, send a first message) anchors the right column.

​
Read the latency card

Avg Latency is a mean, not a percentile — on a long-tailed distribution the p50 median can sit an order of magnitude below the real average, so the card deliberately reads the mean to match what operators mean by “average”. Because it averages over the rolling 24h window, the number stays meaningful even right after your midnight: a workspace that made calls an hour ago still shows its real average, while a workspace with no API-key traffic in the window shows the unavailable placeholder. A rising mean without a corresponding error-rate move is a slow-dependency symptom; a rising success rate hit alongside it usually means calls failed before the slow leg could finish. Either way, open Developer → API analytics to isolate the slow endpoint.

​
Read the success-rate card

The Success Rate card complements the error rate over API-key traffic: a 2-in-1000 error rate renders as 99.8%. 4xx and 5xx both count against it — rate-limit rejections (429) are included in the denominator, so a workspace that routinely saturates its per-key limits sees the success rate dip alongside the 429 volume on the rate limits console. Sync retries, MCP tool calls, model-preset experiments, and SDK regressions all surface here as the single number most likely to move first. Because the gate is “calls made today”, a brand-new integration reads the placeholder until its first real call, and an idle integration reads the placeholder while the number it last computed stays available on the analytics page. Wire the same series into a KPI alert when you want the drop to page you instead of waiting for someone to open the hub.

​
Filter and correlate

The hub cards are tenant-wide aggregates; the next question is always “which key, tool, or endpoint moved the number”. Drill in on Developer → API analytics:
  • By API key — per-key today / 7d / 30d counts, error count, last-used time and IP. This isolates the noisy key when one integration drags the aggregate.
  • By endpoint — per-endpoint count, errors, and p50/p95 latency, so a latency spike maps to the specific route rather than the account.
  • Request logs — the individual requests behind either table, with status codes and payloads, when a table row needs a diagnosis.
For agent-driven traffic the same drill applies at the tool level: the MCP server catalog lists the tools the key can call, and the error taxonomy on the analytics page separates validation errors (422 carrying the bad field) from auth (401/403) and upstream failures (5xx). A leaked or abused key shows up as a per-key anomaly: an unfamiliar last_used_ip, traffic spikes at off-hours, or a sudden success-rate dip concentrated on one key. Rotate that key from Settings → API keys and confirm on the API keys guide that its usage limits still bind after rotation.

​
Map a spike to its cause

When a card moved, the cause is usually one of four things:
  1. Key rotation or revocation — a rotated key changes which integration the traffic attributes to; check By API key sorted by last-used.
  2. Model-preset or tool-catalog change — if the traffic comes from an AI agent over MCP, a preset change alters which tools the agent calls and how expensive each call is; compare the error-rate move against the model presets history.
  3. New or retired integration — a deployed connector or marketplace app changes volume abruptly; the Request logs console shows the new caller’s paths.
  4. Leaked key abuse — unfamiliar IPs and off-hours bursts on a single key; revoke the key, and the success-rate and latency cards stop counting it within the next aggregation window (the metrics cache refreshes on a one-minute cadence).
Correlate against the error taxonomy: a wave of 422s points at a client-side schema drift, a 401/403 spike at a revoked or mis-scoped key, and a 5xx rise at a platform-side incident you can cross-check against the status page.

​
Feed dashboards and alerts

The hub cards are the dashboard read of the API analytics overview endpoint, and every field is available from a script for the same roles — so a KPI alert, a Grafana panel, or a warehouse export all read the same series. Wire the success-rate series into a KPI alert with a threshold below your normal error complement, and wire the per-key volume series into the usage-anomaly alert rules so an unfamiliar-IP or off-hours spike pages the on-call rather than waiting for a hub visit. The API analytics reader guide lists the exact reads (developers/api-analytics/overview, .../by-key, .../endpoints, .../timeseries) those alerts poll under the hood.

​
See also