Skip to main content
A CPaaS contract is a dependency decision, not only a rate card. Use this checklist to test whether a vendor remains workable if it is acquired, exits a region, or retires a product surface.

​
Ask about vendor failure modes

Require a written answer and supporting evidence for each question. The 2025–2026 CPaaS market makes these questions practical. Amazon Pinpoint entered a documented end-of-life path, Twilio’s deprecation cycle reached product families, and other vendors changed trial, pricing, or channel strategy. Treat a roadmap statement as context, not as a contract remedy.

​
Questions before you sign

  • Who is the carrier of record? Require the vendor to name the responsible carrier or licensed operator for each relevant market and explain the support boundary.
  • Can you bring your own carrier or SIP connectivity? Require a documented production path with credentials, routing, observability, and support boundaries. “Custom project” is not the same as a supported option.
  • Can you test multi-region SIP failover? Require the region map, failover trigger, routing behavior, recovery test, and a non-production drill.
  • Can you inspect operator-level pricing and routing? Require an MCCMNC override surface where the vendor supports operator-specific rates or routes, with effective dates and an audit trail.
  • Is the deprecation policy complete? It should cover APIs, SDKs, webhooks, numbers, channels, models, and dashboard controls, not only API versions.
  • Can you reproduce the invoice? Require base usage, carrier and regulatory surcharges, number fees, minimums, currency treatment, and rate-change rules.
  • Can you prove failure behavior? Test delayed, rejected, duplicate, and provider-unavailable events with the same webhook and status formats used in production.
Keep the distinction between vendor-operated infrastructure and tenant-owned controls clear. Consent, suppression, quiet hours, retention, data placement, and evidence records should be configurable and exportable by the tenant; a vendor promise to “handle compliance” is not an ownership model.

​
Hold an exit runbook before go-live

Ask the vendor to demonstrate each item in a sandbox and identify the supporting contract clause or public documentation.
  • Number port-out: Export CSR, LOA, PIN, losing-carrier details, porting status, release timelines, and fees for every number class you use.
  • Template export: Export SMS, WhatsApp, RCS, email, and voice templates with variables, approval state, locale, media references, and versions in a readable format.
  • Webhook portability: Document event names, payload fields, signatures, retries, ordering, and replay or history export.
  • Historical log export: Export message events, call detail records, recordings or metadata, error codes, timestamps, and billing identifiers for the full retention period.
  • Consent-receipt export: Export tenant-owned consent evidence, disclosure text or template version, timestamp, source, recipient identity, revocation, and suppression history.
  • Credentials and cutover: Rotate keys, stand up a replacement receiver, shift traffic gradually, and revoke old credentials without waiting for vendor support.
  • Commercial closeout: Reconcile final usage, number rental, carrier charges, taxes, credits, and refunds from a file finance can read.
If an item is “available on request,” treat it as unverified until your team receives and opens the file. Portability is an operational property you test, not a sentence in a sales deck.

​
Apply the same standard to Devotel Orbit

Devotel Orbit publishes buyer-facing evidence for the same questions: the dashboard exposes an MCCMNC rate-override surface under the admin billing routes, the multi-region SIP failover guide documents the voice design, and the carrier-of-record explainer describes network ownership. Evaluate those links, run the failover and export tests, and apply the same yes/no standard to Devotel Orbit that you apply to every other vendor.