Frequently asked questions

Devotel Orbit is the Agentic Customer Communications Cloud — one platform spanning nine aaS pillars (CPaaS, CCaaS, UCaaS, AIaaS, NaaS, CSPaaS, RTC PaaS, CXaaS, CDPaaS) with APIs for SMS, WhatsApp, RCS, Viber, Email, and Voice, plus AI-native features like autonomous agents, visual flow builders, and intelligent routing. Build with the CPaaS APIs or run a finished internal phone system on the same tenant.

SMS (global coverage in 190+ countries), WhatsApp Business API (template and session messaging), RCS (rich messaging on Android devices), Viber, Email (transactional and marketing), and Voice (outbound and inbound calls, SIP trunking, IVR, and AI voice agents) — six channels on one bill.

On Google Cloud Platform (GKE Autopilot) in the europe-west1 region (Belgium), with data stored in Cloud SQL PostgreSQL 16 with at-rest encryption.

Pay-as-you-go with no monthly subscription tiers: pre-load credits and outbound usage (messages, voice minutes, AI agent invocations) deducts at per-channel rates. There are no Starter, Growth, or Business subscription plans — only PAYG and Enterprise (negotiated rate card).

Credits are purchased in advance through the dashboard or Stripe Checkout and consumed for messages, voice minutes, and agent invocations. Credits never expire. Enable auto-top-up in Settings → Billing → Auto top-up to prevent service interruption.

No free tier and no automatic trial credit: every account is pay-as-you-go — after KYC approval, fund the balance with a top-up before sending live traffic. The sandbox environment is free to test with before going live.

No — one provider wins on coordination (a shared API client, unified support, one procurement approval and one pay-as-you-go bill), while splitting genuinely wins when a per-channel capability island exists (a niche codec, a region a generalist cannot serve, a deliverability hedge) or when concentrated risk outweighs the orchestration value. Weigh the trade: per-channel API complexity against coordination overhead in SLAs and billing consolidation.

When a per-channel capability island exists that no unified provider matches — a deliverability hedge, a region only one vendor serves — or when a specialization outweighs the consolidation overhead the one-provider mode removes. Refusing to weigh that counterexample is the dishonest part of most single-provider content; the split is the right move for a genuinely one-channel requirement or a deliberately-diversified mission-critical layer.

All phone numbers are in E.164 format — the plus sign, country code, then the subscriber number, e.g. +14155552671 (US), +447911123456 (UK).

A purchased number idles at pending_compliance until a compliance profile — the named, reusable packet of verified business data the carrier reviews (see the docs glossary entry "Compliance Profile") — is attached and approved; the number cannot send or receive until then. Attach an approved profile with POST /api/v1/numbers/:id/attach-compliance-profile and the carrier webhook flips the number to active. If the grace window lapses first, the auto-release sweep refunds the captured monthly cost to your wallet — the two exits are attach-an-approved-profile or refund-on-release.

Yes — every outbound US call is signed with a STIR/SHAKEN PASSporT. The attestation level resolves at dial time from how you hold the caller ID: a platform-owned number attests at A (full), a leased number at B (partial), and an external caller ID sits at C (gateway) until you register a delegate certificate that lifts it to B — C to B is the deliberate ceiling, only ownership earns A. The attestation tier also feeds the cross-channel Trust Score on the Brand Identity page alongside 10DLC, toll-free, and WhatsApp registrations, so closing the level raises the score buyers and carriers read back.

All tenant data runs on Google Cloud in europe-west1 (Belgium) with at-rest encryption, and voice carries a per-workspace resident-region pin. A pin starts advisory — it records intent (`enforced: false`) without promising region-scoped storage — and turns enforced only on a provisioned region; a preview region can be pinned advisorily but never enforced. Once a pin is enforced, locking it makes the region immutable: a region change on a locked pin is refused with 409 RESIDENCY_LOCKED, and the deliberate path is the audited unlock call, a governed region migration, then re-lock — never a silent re-home.

queued means the message has not been handed to a sender or provider yet — the hold is on your side of the handoff, not carrier-side. The usual causes are a future send_at time (the row is scheduled, not broken), a quiet-hours or compliance send gate, an exhausted sender pool, an email warm-up cap, or provider connectivity trouble. List the stuck rows in the Delivery Log with the queued filter, clear the one hold the cause table names, and retry only after the cause is resolved — a blind retry just re-queues the same hold, while double-sending a copy duplicates once the hold clears.

Template lifecycle events — template submitted, approved, rejected, auto-paused, and quality updates — are distinct webhook event types: a subscription scoped to message.* events never notifies on a template review or a post-migration quality change, so add them explicitly (or subscribe to all events). When an event does fire but your handler stays quiet, the duplicate-delivery pattern is the next check — deliveries are at-least-once, so dedupe on the stable event id.

Four things: your WABA id; the stage it froze on — release from the source BSP, partner assignment, Embedded Sign-up, template sync, or webhooks; the exact error text verbatim with one attempt timestamp; and the source BSP name plus whether their release is confirmed. That payload routes the case straight to the right lane — Meta escalation versus connection repair — without a back-and-forth.

The sender pool resolved fine but its member list has no senders in it — you routed traffic through an empty pool. Add at least one phone number, short code, or alphanumeric sender ID to the pool before sending.

US and Canada carriers reject the shared alphanumeric sender, so the implicit default for a +1 recipient swaps to a platform phone number. Pass an explicit sender or a sender pool to pin the sender identity — the fallback chain and the per-country rules are in the docs.

Strict sender-ID mode is an opt-in tenant control that rejects a non-conforming alphanumeric sender before you send it, instead of letting the carrier reject it later. Default is off (permissive): a violating sender is accepted with a non-blocking deliverability advisory on the message. Once enabled — from the dashboard sender-ID settings — every outbound alphanumeric sender is checked against the destination country's length, prefix, and character rules, and a violation returns 422 SENDER_INVALID_FOR_DESTINATION before any credits are deducted.

Check the agent's presence state per queue membership. Presence has five states — available, busy, wrapup, paused, offline — and dispatch rings only memberships whose worst state across every queue is available, so one leftover wrap-up on a second queue blocks the ring. The softphone away toggle maps to paused at storage, so an on-shift-looking agent can be parked by a paused membership; the attendant console tiles the live grid per queue.

Dispatch eligibility is a hard gate: the dispatcher rings an agent only when their queue-membership state is available, they are a member of the queue, and their skills cover it. An agent who looks available on one queue can still be skipped — the dispatcher reads the worst state across every queue membership, so one leftover busy or wrap-up elsewhere blocks the ring, and a presence toggle mapped from the softphone's four-state vocabulary can invisibly park an agent the dashboard shows on-shift. Check the agent's state per queue before blaming routing.

Delivery channels — sms, whatsapp, email, voice, viber, telegram, rcs, and flashcall — carry a code to the recipient. Factor channels — totp, push, backup_code, sna, silent, and magic_link — validate possession of a secret or device with no code delivered, and are enrolled and verified through their own /verify/factors/*, /verify/push/*, and /verify/passkey/* endpoints.

A 429 with RATE_LIMIT_EXCEEDED means one of three rate-limit layers tripped: the per-API-key limit, the org-wide per-recipient limit, or the per-recipient brute-force lockout that stops code-guessing attacks. Honour the Retry-After header when present and retry instead of hammering the endpoint; VERIFY_RESEND_COOLDOWN (also 429) is the per-recipient OTP resend cooldown tripping on a re-send, distinct from the org-wide layers.

A direct send expires after 600 seconds (10 minutes) by default; set expirySeconds on a verify profile (up to a 60-minute ceiling) to change it. max_attempts (1–10, default 3) caps how many /verify/check calls can guess a code before the verification fails and needs a fresh send; a /check that arrives after expiry returns 410 EXPIRED_TOKEN and a wrong code returns 422 with the remaining attempts.

A squad is a multi-agent unit in which one classifier agent routes each inbound conversation turn to the right specialist member. Each member carries an agent id, one to ten intent labels, and a description the classifier uses to disambiguate; a fallback agent catches the turn when no member matches. Squads are managed in the dashboard at Agents → Squads, with utilization visible from analytics through live monitoring.

Agent ROI puts each agent's model-call cost — the LLM token spend recorded for its conversations in a window — against the attributed revenue of the outcomes it resolved, and reports the difference as a margin. Attributed revenue is your own value-per-outcome assumption priced onto resolved conversations, not billed revenue, so the numbers are only as meaningful as the estimate you set. Read the per-agent cost, revenue, and margin in the dashboard at Insights → Agent ROI, or over the Insights API.

Loop shapes: squad members of the same squad cannot be chained as handoff targets, so every chain of handoff targets resolves to a terminal agent. If the API detects a cycle it rejects the create or update with a 422, keeping the routing loop acyclic so a conversation never bounces between members indefinitely.

The golden record is the merged best-value profile for one contact or account: every trait that survives the identity rules' recency-based merge becomes the single authoritative entry. New identifiers — a phone, an email, an anonymous id that later resolves — keep folding into the same record, so scoring, segmentation, and reporting always read one clean row instead of duplicate fragments.

Two seams: a real-time bind calls POST /sdk/identify with the anonymous id plus a phone or email as soon as the site learns who the visitor is, backfilling every pre-identify browser event onto the resolved contact; or an operator declares the link later with POST /api/v1/cdp/identity-stitch when a backend job discovers the mapping. Re-calling the platform-side bind is a no-op once the contact exists, so the integration is idempotent.

Accounts are first-class golden records keyed by an explicit group_id, built by the same recency survivorship as contacts. You relate a member contact to an account, a parent account, or both by sending the relationship trait on the same call that identifies the account; the golden record aggregates group traits, and account-scoring reads the hierarchy to rank intent and churn at the account level.

Two tenant-owned knobs: per-channel organization gates you toggle per channel, and a campaign fallback window that applies when the campaign itself carries no explicit window. Resolution order for a campaign send is the campaign row's own window, then the org fallback, then the platform default 21:00 → 09:00 recipient-local.

It holds, it is not lost. SMS-class sends wait for the recipient-local window (the TCPA posture is 08:00–21:00) and dispatch automatically the moment it opens; email is exempt from the TCPA window. Numbers with an unknown timezone fail open by default, so attach a timezone to contacts when you want strict hold behavior.

Open Settings → API keys in the dashboard, expand the key's analytic drawer, and use the Usage budget card: set a monthly request ceiling for that key and Orbit grades the key's live 30-day usage against it — a caution badge once consumption crosses 80% of the ceiling, a budget-exceeded badge at 100%. Budgets are stored in your browser, not on the API, so it is an early-warning tripwire; the hard quota in the usage-limits guide is what blocks traffic.

It returns a computed day-by-day ramp: the daily send caps that grow a fresh sending IP or domain from a conservative day-1 volume (default 50/day) up to the target daily volume, at a default ~50%/day growth factor. A companion status endpoint reports which ramp day the account is on, today's recommended cap, how much has already gone out, and the remaining headroom, and an enforcement endpoint turns a requested batch size into an accept/defer decision against today's live cap.

Respect the daily cap: throttle or gate the send instead of pushing full volume, and use the warmup-enforcement endpoint as the one authoritative accept/defer decision. The same ramp principle applies to a newly provisioned long code, short code, or alphanumeric sender ID — start with a small daily cap to engaged recipients with full SPF/DKIM/DMARC in place.

Every webhook includes an X-Orbit-Signature header (the canonical HMAC-SHA256 signature); a legacy X-Devotel-Signature header is also included for backwards compatibility. Verify either signature by computing the HMAC of the raw request body using your webhook secret.

Orbit retries failed deliveries on an exponential backoff schedule: up to 9 retries with a 30-second base delay (doubling with each attempt), spanning roughly 4.3 hours end-to-end, plus up to 20% jitter on each delay. After all attempts are exhausted, the event goes to a dead letter queue, and failed deliveries are reviewable in the dashboard.

sent is a wire-intermediate state — Devotel Orbit submitted the message to the carrier, but no handset receipt came back yet. Only delivered is carrier-confirmed. undelivered means the carrier tried the handset and could not reach it, and failed is the exhausted-retries or classified carrier failure. A delivery receipt (DLR) is the status callback that moves a message across these states; some carriers send corrections minutes after a first receipt, and Devotel Orbit honors the latest transition. The glossary entry (/glossary/dlr) defines the receipt itself.

queued means the message has not been handed to a sender or provider yet — the hold is on your side of the handoff, not carrier-side. The usual causes are a scheduled send time, a quiet-hours gate, an exhausted sender pool, an email warm-up cap, or provider connectivity trouble. List the stuck rows in the Delivery Log filtered to queued, clear the one hold the cause table names, and retry only after it is resolved — a blind retry just re-queues the same hold.

Yes. Every Application-to-Person SMS to US numbers requires 10DLC registration through The Campaign Registry — the brand and campaign are declared to the US carriers, and unregistered traffic over long codes is filtered or rejected. The registration guide walks the brand, campaign, and vetting steps, and explains the per-carrier review map to read once a campaign is approved.

An alphanumeric sender ID is a brand name shown as the SMS origin — up to eleven characters — instead of a phone number. It works where local carriers accept it (much of Europe, Asia, and Africa), often only after pre-registration. US and Canada carriers reject alphanumeric senders outright, so a +1 recipient always sees a phone number instead; many other markets overwrite or filter unregistered IDs.

Warm-up is the gradual ramp a new sending number, domain, IP, or sender ID follows so carriers build a sender reputation before full volume flows. A fresh 10DLC number starts on a small daily ceiling that grows through the warming phases, and sends past today's cap are refused with a retryable status. Keep volumes to engaged recipients with complaint rates low, and the ceiling rises — reputation is earned per sender, per destination.

End-to-end. Sending RCS on Orbit is a shipped path, not a pilot: you register a branded RCS agent (bot) — the brand form, the agent, carrier verification, and launch travel together through one registration, rich cards and carousels send the moment the bot is launched, and a capability probe pre-checks each recipient. When a recipient cannot take RCS, the org-level cross-channel fallback chain cascades to SMS with one shared message_group_id so the two legs stay one conversation; the Trust Score on your Brand Identity page carries the rcs_business surface alongside 10DLC and STIR/SHAKEN.

DLR latency is two planes: the wire accept (submitted to the carrier) and the asynchronous receipt (the carrier's delivery confirmation). A row sits at submitted_no_receipt when the per-channel grace window closed with no receipt — on SMS/MMS/voice/fax/RCS that window is 30 minutes, on email it defers to the Resend-side reconciler, and on instagram/messenger the Meta Send API never emits receipts so the sentinel is the expected terminal. A late receipt still reconciles and rewrites the row, so treat submitted_no_receipt as 'outcome unknown', not as failure: the aging scheduler promotes a genuinely-no-receipt SMS row to terminal undelivered with a message.failed webhook plus a refund, and never counts the sentinel as a hard failure. Do not retry while a row is at sent or submitted_no_receipt.

Compliance gates are tenant-owned and open by default: you decide which controls enforce and which observe. An enabled toggle may not block yet because the control is still warming to its enforcement threshold or an external approval is pending; ops-facing controls are fail-open where a hard stop would break sends, and privacy / consent controls are fail-closed. The full posture map covers which controls fail open versus closed, which approvals carry external lead time, and the tenant-owned toggle surface.

You do. Every compliance control is a tenant-owned toggle, and the posture map lists each one with where the switch lives and its default. Your posture is additive: everything starts open except the hard asymmetries the platform deliberately does not let you toggle — the US state calling-window overlays, for example. Orbit ships the controls; which controls enforce, and which only observe, is your call.

A send gate is one of the regulatory checks Orbit runs at send time — quiet hours, Do-Not-Call, Reassigned Numbers, Robocall Mitigation, HIPAA BAA, and the voice pre-flight blocks. Each gate is a per-decision additive toggle: a message is held when it trips its specific gate layer, never dropped, and dispatches the moment it clears. Preview before you blame a layer — the preview endpoint reports which gate closed and when it opens.

Orbit resolves the recipient's local time from their phone number's region and evaluates your window on it — the org-wide per-channel gate first, then the campaign fallback window, then the platform default. A held send defers, it is never dropped, and the preview endpoint returns the exact next_allowed_at timestamp so you can schedule around the window. Defaults: 08:00–21:00 recipient-local for SMS/voice, 09:00–21:00 for WhatsApp and other Meta channels.

The self-service intake portal proves the requester's identity with a two-factor challenge — an OTP sent to their email plus one to their SMS — before the request is queued, and the proof is recorded as auditable evidence. Once identity is proven, the portal files the access, delete, or portability request and returns a public reference id (dsar_pub_…) the requester uses to look up status. Your operators can also file operator-side requests through the authenticated API, but the portal never trusts an unverified verdict.

Regulated markets want proof of who you are: passports, national ID cards, business registrations, VAT certificates, utility bills, and proof of address among the supported types. Upload each once into your document library and it gets a doc_… reference id; compliance profiles cite that reference instead of the raw file, and destinations — numbers and Sender-ID registrations — attach the profile. The same doc_… id is reused across every destination and renews in one place before it ages out.

Both are shipped, per-organization features. SAML 2.0 SSO is owner-managed under Settings → Security with both entry points live: IdP-initiated login from your IdP's app portal, and SP-initiated login from Orbit's /auth/saml/{orgSlug}/login entry point, with a published SP metadata URL to import and an ACS callback to paste into the IdP. SCIM provisioning is the separate membership question: your IdP (Okta, Microsoft Entra, any RFC 7643/7644 client) pushes create, update, soft-block (active: false), and deprovision operations to the org-scoped base URL /scim/v2/{orgSlug} over a dedicated Bearer token configured under Settings → SCIM, so a person exists as a member before their first login.

The score — reported for your organization, each sending number, and each campaign — is a weighted blend of four carrier-risk signals: consent coverage, opt-out velocity, STOP-reply rate, and carrier rejections, bucketed into a healthy/at-risk/critical band. It is deliberately read-only: it never blocks a send or suppresses a contact, so a cosmetic score check cannot take down traffic. A falling score is your early warning that a carrier is about to throttle — what you do with the signal is your call.

Email support@devotel.io, use the in-app chat help widget in the dashboard, or — on Enterprise — reach the dedicated Slack channel and account manager.

status.orbit.devotel.io carries real-time platform status, incident history, and maintenance schedules.

Email security@devotel.io. Reports are answered within 24 hours and handled under responsible disclosure practices.