Skip to main content

Manage Orbit from the terminal with the devotel CLI

The devotel CLI is the first-party command-line tool for scripting sends, listing numbers, tailing real-time request logs and delivery receipts, and forwarding live webhooks to your machine. It ships hand-maintained types against the platform’s public API, so what you automate is the same contract the SDKs and dashboard use. This page walks the whole surface: install, login, first send, live logs, local webhook forwarding, numbers and sandbox, profiles and JSON output, Twilio migration, and troubleshooting. Every example below is copy-pasteable once you have an API key. The full command surface: Run any of them with --help, or devotel help for the full usage text.

Install

The package installs a single devotel binary. Check it landed:

1. Log in with an API key

Mint an API key from Dashboard → Developers → API keys, then store it:
Credentials live at ~/.devotel/config.json with 0600 permissions. Check the active identity at any time:
The printed token is always redacted, so the command is safe to paste into a ticket or a chat thread.

2. First send

Every account has sandbox numbers to send from before you provision a real one, so the first-send loop is three commands:
The queued status confirms the request was accepted. Outbound SMS goes through Devotel’s own wholesale network — nothing you run here touches upstream carriers from your machine.

3. Watch it land in real time

devotel logs tail streams request logs and delivery receipts (DLRs) as they happen:
Each line is one event: timestamp, level, method, status, path pattern, and message. DLRs show up as delivery events on the message id, so you can watch a send go queued → delivered without opening the dashboard. Add --json for one JSON object per line if you are piping into jq. Stop the stream with Ctrl-C.

4. Local webhooks

Build a webhook handler on your machine without deploying or standing up a public tunnel. devotel listen tails your tenant’s live events and POSTs each one to your local server:
Each forwarded request carries an X-Devotel-Signature: t=<ts>,v1=<hmac> header, signed with the secret the CLI printed on startup — the same scheme the production dispatcher uses. Verify it exactly as you would a live webhook:
Useful flags:
  • --types <csv> — only forward these event types, e.g. --types message.delivered,message.failed.
  • --secret <whsec_…> — reuse a fixed signing secret (or set $DEVOTEL_WEBHOOK_SECRET) instead of a fresh per-session one, so you can hard-code it in your local .env.
  • --replay — also forward the events buffered before you started, then keep tailing. Use this when your handler needs to process backfill, not just live traffic.
Verify signatures on every request — local or production. The walkthrough on verifying webhook signatures covers the per-language one-call verifiers if you find a mismatch.

5. Numbers and sandbox

Two read commands cover your inventory:
numbers list shows every provisioned number; sandbox numbers shows only the free-to-send sandbox pool. Use the sandbox pool when you are prototyping so you never burn a real number on a smoke test.

6. Profiles and JSON output

Keep separate credentials per environment with named profiles:
Profiles are keyed in ~/.devotel/config.json, so switching shells does not clobber a colleague’s setup. Clean up a profile with devotel auth logout --profile <name>. Add --json to any read command for machine-readable output — the CLI emits one JSON value that you can pipe into jq:
--json is also the right flag when you script devotel migrate status <jobId> in CI and want a structured status.

7. Migrate from Twilio

devotel migrate twilio drives the same one-click migration wizard the dashboard’s Import screen uses, from your terminal or a CI pipeline. It always runs a dry run first — nothing is written until you pass --run:
By default it ports phone_numbers, messaging_services, templates, and contacts; narrow it with --entities phone_numbers,contacts, or shrink the contact/message lookback window with --conversation-days 30. Your Twilio Auth Token is exchanged server-side for a short-lived encrypted envelope and is never written to ~/.devotel/config.json. The migration moves configuration and metadata — not live traffic. For the full concept mapping (SMS, voice, webhooks, Verify) see the Twilio migration guide.

8. Troubleshooting

Credentials are written to ~/.devotel/config.json with 0600 permissions — user-readable only, so no other account on the machine can read your tokens. To move the file (useful in CI) set DEVOTEL_CONFIG_HOME to an alternate directory; every command then reads from (and auth login writes to) that location instead.

See also

  • Verify webhook signatures — the one-call verifier per language, applied to both forwarded and live events.
  • Migrate from Twilio — the full concept mapping this page’s migration section previews.
  • SDKs index — per-language libraries for the same public contract the CLI is typed against.
  • Tour the Developer hub — where the API keys page lives, and the surrounding feature map.