> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Developer hub overview: read the latency and success-rate cards

> How to read the Developer hub's computed KPI cards — API calls today, average API latency, request success rate, and active keys — and use them as the entry point for per-tool, per-agent, and per-key diagnostics.

# 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](/guides/api-request-logs-console), [API analytics](/guides/api-analytics-reader), [rate limits & quotas](/guides/api-rate-limits-console) — 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](/guides/api-request-logs-console), [API analytics](/guides/api-analytics-reader), [Rate limits & quotas](/guides/api-rate-limits-console), 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](/guides/api-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](/guides/kpi-alerts) 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](/guides/api-key-usage-limits) 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](/guides/agents-model-presets) history.
3. **New or retired integration** — a deployed connector or marketplace app changes volume abruptly; the [Request logs](/guides/api-request-logs-console) 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 `422`s 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](/guides/kpi-alerts) with a threshold below your normal error complement, and wire the per-key volume series into the [usage-anomaly alert rules](/guides/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](/guides/api-analytics-reader) guide lists the exact reads (`developers/api-analytics/overview`, `.../by-key`, `.../endpoints`, `.../timeseries`) those alerts poll under the hood.

## See also

* [API playground](/guides/developer-api-playground) — build and send requests from the dashboard when you need to reproduce a failing call
* [API analytics reader](/guides/api-analytics-reader) — the read-only dashboards the hub cards summarize
* [Rate limits & quotas console](/guides/api-rate-limits-console) — set the org-wide default and per-key overrides when the success-rate card is healthy but throughput is capped
* [Request logs console](/guides/api-request-logs-console) — the individual requests behind the aggregates
