Security Best Practices
Protect your Orbit integration with proper API key management, webhook signature verification, and security hardening.API Key Management
Key Types
Orbit uses four types of API keys:Key Security Rules
- Never expose secret keys in client-side code. Secret keys (
sk_) should only be used in server-side environments.
- Use environment variables. Never hardcode keys in source code.
- Rotate keys regularly. Generate new keys quarterly and revoke old ones.
-
Use separate keys per environment. Use test keys (
dv_test_sk_) for development. - Restrict key permissions. Create keys with minimum required scopes in the dashboard under Settings > API Keys.
Revoking a Compromised Key
If a key is exposed:- Go to Settings > API Keys in the Orbit dashboard
- Click Revoke on the compromised key
- Generate a new key
- Update your application configuration immediately
Webhook Verification
Every webhook from Orbit carries an HMAC-SHA256 signature in theX-Orbit-Signature header — the canonical, productised signature. For back-compat we also emit X-Devotel-Signature with the same value, so older integrations that read it keep working. Verify the signature (from either header) before processing webhook payloads.
Signature Format
The header is Stripe-style, not a bare hex digest:t=<unix>— Unix timestamp (seconds) when Orbit signed the payload. Use this for replay protection.v1=<hex>— HMAC-SHA256 of<t>.<raw_body>keyed by your webhook signing secret. Hex-encoded.
X-Devotel-Signature carries the identical t=...,v1=... value for back-compat. Prefer X-Orbit-Signature, and fall back to X-Devotel-Signature when the canonical header is absent.
During a secret rotation grace window the signature includes two v1=<hex> values (new secret first, previous secret second). Your verifier should accept the request if any v1 matches your computed HMAC. Orbit additionally sends a standalone X-Orbit-Signature-Next header during the grace window carrying the rotation-candidate signature; it is omitted outside the window, and verifiers that already iterate the v1 candidates can ignore it.
How Verification Works
- Parse
X-Orbit-Signature(or the back-compatX-Devotel-Signature) intotand one or morev1candidates. - Reject the request if
tis older than 5 minutes (replay protection). - Compute
expected = HMAC_SHA256(secret, "<t>.<raw_body>")as hex. - Compare each
v1candidate againstexpectedusing a timing-safe comparison.
Implementation
Node.js
Python
Go
Webhook Security Checklist
- Read
X-Orbit-Signature(the canonical header), falling back to the back-compatX-Devotel-Signature - Parse the signature as
t=<unix>,v1=<hex>[,v1=<hex>]— never as a bare hex digest - Reject signatures whose
t(timestamp) is older than 5 minutes (replay protection) - Accept the request if any
v1matches (covers secret rotation grace) - Use
timingSafeEqual(or equivalent) to prevent timing attacks - Respond with
200within 30 seconds to avoid retries - Use HTTPS for all webhook endpoints
- Store webhook secrets securely (environment variables, secret manager)
Transport Security
HTTPS Required
All Orbit API endpoints require HTTPS (https://api.orbit.devotel.io). HTTP requests are rejected.
TLS Requirements
- Minimum TLS 1.2
- TLS 1.3 recommended
- Weak cipher suites are not supported
Webhook Endpoint Requirements
Your webhook endpoints must:- Use HTTPS with a valid SSL certificate (not self-signed)
- Support TLS 1.2 or higher
- Respond within 30 seconds
- Return a
2xxstatus code to acknowledge receipt
IP Allowlisting
If your firewall restricts inbound traffic, allowlist Orbit’s webhook delivery IPs:IP ranges may change. Subscribe to the Orbit status page for notifications about infrastructure changes.
Data Security
PII Handling
- Orbit masks phone numbers in logs (
+1415555****) - API responses include full data; mask PII in your own logs
- Use metadata fields for internal identifiers instead of PII
Data Retention
Encryption
- In transit: TLS 1.2+ for all API and webhook traffic
- At rest: AES-256 encryption for all stored data
- Recordings: Encrypted at rest with per-tenant keys
RBAC (Role-Based Access Control)
Orbit supports ten roles. Five are general-access roles with increasing permissions:Specialized seats (least privilege)
The remaining five are least-privilege operator seats. Each is ranked belowviewer in the role hierarchy, so it grants only the surfaces it is explicitly assigned to — it does not inherit the general read routes (analytics, messages, numbers, …) that viewer and above receive. None of these seats can configure voice routing, send messages, manage billing, or manage the team, and none can alter outbound voice/SMS routing.
Assign the minimum role needed for each team member.