Skip to main content

​
Tour the Developer hub

The Developer section of the dashboard is a hub, not a single tool: it collects every surface you touch while building and operating an integration — minting credentials, trying requests, reading what your code actually sent, and pushing events into your own infrastructure. Each tile on the hub’s landing page is one of those surfaces. This page is the map: it tells you what each tile does in one sentence and hands you off to the guide that covers it in depth — nothing is walked through twice here.

​
Where the hub lives

Open the dashboard and pick Developer in the left navigation. The hub’s landing page shows one tile per surface, grouped by what stage of an integration it serves, plus four computed cards on top — API calls today, average latency, success rate, and active keys. Read the overview cards covers those cards and how to drill from one into diagnostics. The hub is built for the developer-facing roles on your organization: owner, admin, and developer accounts see the Developer entry in the navigation. A viewer account does not see the hub itself — a read-only analytics surface is the exception, covered in Who sees what below.

​
The hub map

Tiles in the order you reach for them, grouped by what they do. A linked tile has a dedicated guide; follow it for the full walkthrough.

​
Credentials and control

​
Try and inspect

​
Events and delivery

​
Integrate elsewhere

​
Channel edges and utilities

​
Suggested order of setup

New integrations on the hub go smoothest in this order — each stage feeds the next one:
  1. Keys — mint a key from the API Keys tile (it opens Settings), scope it to the channels you actually call, and name it so rotation is obvious. Choose and scope API keys.
  2. Scopes → limits — set a per-key rate limit and monthly quota in API Governance before traffic lands, not after. API governance console.
  3. Sandbox — run the whole flow against sandbox and test mode first: magic-number sends, canned receipts, simulated inbound.
  4. First request logs — send one real request and find it in the Request Logs console: confirm the payload and status you expected before building further.
  5. Webhook consumer — receive inbound events, verify signatures, and dry them against the Webhook Tester. Write a webhook consumer walks the full loop.
  6. Event sink — when per-endpoint webhooks stop scaling, point an event sink at your Kafka topic or HTTP collector for production fan-out.

​
Who sees what

The Developer entry in the dashboard navigation appears for the owner, admin, and developer roles only — those same three roles gate the hub’s server-side routes, so an unprivileged account that deep-links in is turned away rather than seeing stub tiles. Grant or revoke higher roles under Organization → team management when you need to widen access. The one read-only exception is API Analytics: its dashboards and their underlying read endpoints also accept the viewer role, so the people who watch your integration’s health can see the same numbers from a viewer seat. API analytics dashboards details the four-role gating there. Everything else — minting keys, rotating webhook secrets, governing limits, configuring sinks — stays at developer and above.

​
See also