Skip to main content

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

  1. Never expose secret keys in client-side code. Secret keys (sk_) should only be used in server-side environments.
  1. Use environment variables. Never hardcode keys in source code.
  1. Rotate keys regularly. Generate new keys quarterly and revoke old ones.
  2. Use separate keys per environment. Use test keys (dv_test_sk_) for development.
  3. 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:
  1. Go to Settings > API Keys in the Orbit dashboard
  2. Click Revoke on the compromised key
  3. Generate a new key
  4. Update your application configuration immediately
Revoking a key is immediate and irreversible. All requests using the revoked key will return 401 INVALID_API_KEY.

Webhook Verification

Every webhook from Orbit carries an HMAC-SHA256 signature in the X-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

  1. Parse X-Orbit-Signature (or the back-compat X-Devotel-Signature) into t and one or more v1 candidates.
  2. Reject the request if t is older than 5 minutes (replay protection).
  3. Compute expected = HMAC_SHA256(secret, "<t>.<raw_body>") as hex.
  4. Compare each v1 candidate against expected using a timing-safe comparison.

Implementation

Node.js

Python

Go

Webhook Security Checklist

  • Read X-Orbit-Signature (the canonical header), falling back to the back-compat X-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 v1 matches (covers secret rotation grace)
  • Use timingSafeEqual (or equivalent) to prevent timing attacks
  • Respond with 200 within 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 2xx status 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 below viewer 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.

Security Headers

Orbit API responses include security headers:
Found a security vulnerability? Report it to security@devotel.io. We take all reports seriously and respond within 24 hours.