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 in the sidebar under Admin → Developer (/[locale]/developer); every console the cards summarize — Request logs, API analytics, rate limits & quotas — is one tile away. You need the owner, admin, or developer role: the sidebar shows the Developer entry to those three roles only, and the hub itself is gated server-side the same way. A viewer kept out of the hub can still be given a standalone surface like Request logs by direct link when your workspace policy allows it.

​
What the Developer surface includes

The tiles below the cards are the map of the developer area. Each one is a full console:
  • Playground — build an API request from the OpenAPI spec and send it against your live account without leaving the dashboard. See the two-way door.
  • API reference — an interactive OpenAPI reference for every endpoint, with request/response samples.
  • API keys — create, scope, rotate, and revoke keys; read per-key usage limits.
  • API analytics — the tenant-wide and per-key dashboards the hub cards summarize.
  • API governance — review how keys and integrations are used across the workspace.
  • Postman — download the maintained Postman collections and environment templates.
  • SDKs — the language catalog: Node, web, Python, Go, Ruby, PHP, Java, C#, and the browser softphone demo.
  • GraphQL — the tenant GraphQL endpoint and explorer.
  • MCP — MCP server connection details for code editors and agents, with the tool catalog.
  • Network APIs — CAMURA-style network API surfaces bundled into the account.
  • Webhooks — register and manage outbound webhook endpoints and their event subscriptions.
  • Webhook tester — send a signed test event to an endpoint and read the delivery result.
  • Event sources — inspect the event sources that feed sinks and webhooks.
  • Event sinks — stream events into your storage and stream-processing destinations.
  • Request logs — individual API requests with status codes, payloads, and timing.
  • Delivery logs — message-level delivery receipts (DLRs) per channel.
  • Sandbox — the isolated test workspace with test credentials and test numbers.
  • SDK demo — run the hosted SDK sample against your account in the browser.
  • SMTP — SMTP relay credentials and connection settings for transactional email.
  • SMPP — SMPP bind settings for connecting an external SMS gateway.
  • Connectors — external integration connectors with install config.
  • Connected apps — third-party apps authorized on your account.
  • Marketplace — browse, install, and publish marketplace apps.
  • QR tools — QR-code generation utilities for scan-to-contact flows.
  • Video embed demo — embed a LiveKit video room on a page.
  • Sync, Event sources, Playground tutorials — the remaining deep consoles linked from the tiles.
Menu path: all of these live under the single Developer group in the sidebar’s Admin section — the hub is the landing page, the rest are its tiles. The sidebar entry appears for owner, admin, and developer roles; a viewer never sees the group.

​
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.

​
The two-way door: Playground vs Postman

Both surfaces let you fire real API requests without writing code first — pick by where you intend to keep the artifact:
  • API playground stays in the dashboard. It reads the live OpenAPI spec, so route shapes are never stale; it executes against your real workspace, so the results show up in Request logs immediately. Use it to reproduce a failing call, to try a parameter you are unsure about, or to produce the request a support ticket needs. For a guided first-pass, follow the API playground tutorial.
  • Postman collections & recipes move the work into Postman, where you can save the collection into your repository, share it with a teammate who has no dashboard seat, layer it into environment templates per stage (sandbox vs production), and script it into CI. Use it when the request becomes an artifact your team maintains.
A common split: reproduce and triage in the playground (one-off, zero setup), then promote the requests that graduate into a regression suite to the Postman collection your team owns.

​
Webhooks, sinks, and logs: which console answers which incident

Four consoles look at “stuff that left the platform” through different lenses. Rule of thumb:
  • Request logs — your inbound API calls to Orbit. Answer for “did my request arrive, what status came back, what payload was sent”. First stop when an integration says a call failed: find the request, read the status code and validation body.
  • Delivery logs — message-level delivery receipts. Answer for “the API accepted my send — did the message actually reach the handset/mailbox, and what carrier/DLR code came back”. First stop for “sent but not delivered” complaints.
  • Webhook endpoint operations — outbound event delivery to your endpoints. Answer for “did we POST the event to your URL, how many retries happened, was the signature right”. First stop when your consumer says events are missing; pair with the webhook tester to replay.
  • Event sinks streaming — bulk event export to your warehouse/storage. Answer for “are events flowing to my sink, what volume, what lag”. First stop when downstream analytics look stale; pair webhooks (low-latency, per-event) with sinks (bulk, replayable) rather than backfilling one from the other.
Incident triage starter: customer says “no message received” → check Delivery logs for the DLR; no entry at all → check Request logs for whether the send request succeeded; webhook-driven flows where your app never reacted → check Webhook operations for delivery + retry state before blaming your consumer.

​
SDKs and editor integrations

  • Language SDKs — the SDK catalog tile lists every official SDK: Node, web, Python, Go, Ruby, PHP, Java, C#, and more — with the package name and install command per language. The SDKs tab of the docs carries the per-language guides. Prefer an official SDK over raw HTTP when one exists for your stack: key handling, retries, and error mapping are already correct.
  • MCP for code editors — the MCP tile gives you the server URL and handshake to plug Claude Desktop, Cursor, or any MCP-capable agent into your Orbit account, so the editor can call the same tools as an integration. Follow MCP for Claude & Cursor to connect; the tool catalog governs what the agent may do, and all of it shows up in Request logs like any other API-key traffic.

​
Worked example: new key → playground → inspect in request logs

The full new-integration loop in three console hops:
  1. Mint a key. Open Developer → API keys, create a key, and copy it — the secret is shown once. Give it the narrowest scope that covers the calls you plan to try, and set its usage limits while you are there (API key usage limits).
  2. Send one request from the playground. Open Developer → Playground, pick the endpoint you are integrating (say, send a message), fill the body, and send. The playground executes it as that key, so the call is indistinguishable from your future integration’s traffic — including how it shows up in the KPI cards.
  3. Read the result in Request logs. Open Developer → Request logs and find the call by status/timestamp: full request and response, latency, and which key made it. This is the loop you will run for every future incident — the playground to reproduce, the logs to diagnose — and here you have proven it works before the first line of integration code exists.
If the playground call succeeded but your code does not, diff the two request bodies in Request logs — the drift is almost always there: a header the SDK sets, a field casing difference, or a missing idempotency key.

​
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 Developer → 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