Developer console overview
Open Developer in the dashboard’s left navigation and you land on the hub: a grid of tiles, each one an operator or developer surface built on the Developer API — credentials, analytics, logs, events, GraphQL, MCP, network APIs, a try-it playground, and the marketplace. This page is the map: what each tile shows, when you reach for it, and who on your team can open it. Where the tile has a deep-dive guide here, you get the link to it. This hub is the workspace for people consuming and operating the Devotel Orbit API. It is a different surface from the public API reference on this docs site: the reference is task-independent endpoint field documentation, and the hub holds your live, tenant-specific operations. Pick the hub when you need to do something against your organization; pick the reference when you need to know what a field accepts.The tile map
What each tile shows and when it is the right tool.Observe and diagnose
Govern and stream
Query and consume
Network identities
Which tiles open here, and which link out
Two tiles land outside the hub’s own pages, and the card says so on the tile:- API Keys opens Settings → API Keys — the full key-management console lives in Settings, and the hub tile routes there. A
?from=developermarker on the link keeps a breadcrumb back to the hub. - API Reference (the tile) points at the in-app developer portal’s try-it console, which is a product surface — distinct from this docs site’s public reference below.
/developer/<tile> — it renders inside the dashboard without leaving the Developer section.
Who sees which tile
The Developer navigation entry is gated to the owner, admin, and developer roles, and the same gate applies to the server-side routes behind each tile — a viewer account deep-linking in gets turned away with a status page, not hidden tiles. One deliberate exception: API Analytics admits the viewer role as well, so the people watching the integration’s health can read the dashboards without mutating anything. Minting keys, rotating webhook secrets, governing limits, and wiring event transport stay at developer and above.
Grant or revoke roles under Organization → team management.
Quick start per tile
Each row ends at the guide that walks the tile end to end:- API Analytics — read traffic and drill into the rate-limit hits. Read the API Analytics console.
- API Governance — set the org default and per-key overrides before traffic lands. Governance console walkthrough.
- API Keys — scope and usage-limit a key. Choosing scopes and limits.
- Delivery Logs — trace one message by id. Delivery Logs console.
- Event Sources — configure the inbound bus. Configuring event sources.
- Event Sinks — point the stream at your collector. Event sinks walkthrough.
- GraphQL — build the one-request shaped read. Querying with GraphQL.
- MCP — run the handshake and list tools. MCP server handshake.
- Network APIs — run a CIBA pre-send check. CIBA network APIs.
- Marketplace — browse, install, and publish connected apps. Marketplace walkthrough.
Hub or public reference — which one
Use the hub when the task touches your tenant’s live state: mint a key, raise a limit, trace a message, configure a stream, run a request. Use the public API reference when the task is contract-level: confirm request/response field names, enum values, and error codes. The hub and the reference answer different questions — one operates, the other describes.See also
- Tour the Developer hub — the full 28-page walkthrough, including surfaces that group under the hub but don’t show on the landing grid (webhooks, SMPP, SMTP, Sync, sandbox, request logs).
- Developer console consoles — the deeper console-by-console guides for those sibling pages.
- Developer portal guide — the API surface the hub pages are built on.
- Developer overview-page cards — the computed latency/success-rate cards at the top of the hub.