Skip to main content

​
Work through the SDK catalog

Developer → SDKs in the dashboard is a versioned catalog, not a static list: the page asks the server for the live publish status and version of every SDK, so what you see is what is actually installable right now — not whatever was true when your browser last cached a screenshot of it. This page is the walkthrough for that catalog: pick a language, check the version and status it currently serves, copy the install command, run the quickstart, and set an upgrade cadence. You need nothing installed to browse it. To run what you copy, mint an API key from Settings → API Keys — a dv_test_sk_… key against the sandbox, or a live key when you are ready. Details: Authentication.

​
1. Open Developer → SDKs

Open the dashboard, pick Developer in the left navigation, then open SDKs. The Developer entry appears for the owner, admin, and developer roles — see Tour the Developer hub for the full role map. The page loads the catalog from the dashboard’s SDK catalog endpoint and overlays those live values on the bundled copy. Two things that buys you:
  • Live status. A card shows Available only when the published package actually installs; a language whose source exists but whose registry package has not shipped shows Coming soon — the badge gates on the server’s live answer, so a stale cached copy of the page can only ever be wrong in the cautious direction.
  • Live version. The version on each card comes from the same server answer, so the number you see is the current published release, and the API base URL the quickstart snippets point at is the one your deployment actually serves.
If the catalog cannot be fetched, the page still renders from its bundled copy and says so in a warning banner — the versions you see may be behind. Hit Retry before trusting a version number in that state. One exception to “live”: the Downloads count on a card is a static placeholder today, not a fetched metric.

​
2. Pick a language

Each card in the grid is one language: status badge, current version, the copyable install command in per-manager tabs (npm/yarn/pnpm, pip/poetry/pipenv), and — where a per-language docs page exists — a View Documentation link. Pick your language off the card, three ways:
  1. Copy the install command. Open the tab for your package manager and copy the command — npm install @devotel-orbit/node, pip install devotel-orbit-sdk, and so on for each language as it publishes. The two npm SDKs ship under the @devotel-orbit scope; anything still showing Coming soon has no registry package to install yet — for those languages, call the REST API directly while the card says so.
  2. Walk the quickstart at the top of the page. The three-step panel — Initialize → Send Message → Check Delivery — tracks the language pill you pick, and the language and step stay pinned in the URL (?lang=…&step=…), so you can hand a teammate a link that opens on exactly the snippet you mean. The snippets point at the API base URL the catalog serves — your deployment’s correct one — which is why copying from this page beats copying from a screenshot.
  3. Jump to the per-language recipes. A card with backing docs carries View Documentation. The published languages also each have a landing page under SDKs: Node.js, Web, Python — plus quickstart pages for the source-only languages (Go, Ruby, PHP, Java, .NET) and the client/mobile SDKs. The Per-language recipes guide continues the core loop past first send — outbound voice, the OTP round trip, paginated reads.

​
3. Release notes and upgrade guidance

The card tells you what is current; the release notes tell you what changed. They live in three places, by scope:
  • Per-language scope notes. Each page under SDKs leads with what that language wraps today and what is intentionally out of scope (core-scope languages ship an escape hatch for uncovered routes instead of stubs). Read this first when a method you expected is missing.
  • Registry changelog. On the published languages, the breaking-change log is the package changelog on the registry listing the card links — the npm page for @devotel-orbit/node (deprecated versions are called out there), PyPI for Python. Check it before any major-version bump.
  • Platform releases. Contract-affecting changes — a renamed field, a new required scope — land as breaking entries on the changelog, so one RSS subscription covers every SDK at once.
For cadence: pin an exact version in your package manifest, refresh on a regular schedule rather than on every release, and re-run your first send in the sandbox before promoting a major bump. The multi-package-manager install tabs are equivalent — matching the tab to your repo’s lockfile is the entire decision. If a card flipped back to Coming soon after you relied on it, that is a registry deprecation, not a dashboard bug — the card is doing its job; pick the previous published version from the registry listing.

​
4. When to use the docs instead of the console

The catalog answers “what can I install, right now?” Reach for the SDKs index and the per-language pages when the question is anything else:
  • Deciding between languages, before you have opened a dashboard — the index’s scope-by-scope comparison (feature-complete vs core-scope vs client/mobile) is the decision table.
  • Auth, errors, webhooks, escape hatches — the shared contract (constructor shapes, the OrbitApiError tree, one-call webhook verifiers) is written once on the index and per-language page, not repeated in the console.
  • A 401/403 after copying the console’s initialize snippet — the console snippet uses the constructor alias the page’s quickstart shows; the per-language page carries the full constructor reference and the env-var pattern to move to.
If you are skipping SDKs entirely, the API-first path is the Postman collections — import a collection, set the key once, and send a sample request before writing any client code.

​
See also