Skip to main content

​
CSPaaS white-label operations

CSPaaS is communications sold under your brand. You give each customer an isolated workspace, a customer-specific domain, and the operating controls that belong to that tenant. The result is a communications product your customer can use as their own, while you run the platform relationship underneath it. CSPaaS is not the same as reseller aggregation. Aggregation combines carrier or provider access behind one offer. White-label operations add a customer-facing product boundary: sub-accounts, per-tenant branding, custom domains, and a defined operator model. Devotel Orbit provides the platform primitives for this model:
  • Sub-accounts isolate customer workspaces under a parent organization.
  • Branding and custom domains let each tenant present its own dashboard identity and hostname.
  • Vertical bundles provide an industry-shaped starting configuration.
  • Volume tiers and rate cards support the commercial terms you set for each customer.
  • MCP tools can automate approved provisioning and operations when you keep credentials and scopes narrow.
These are tenant-owned controls. Orbit provides the controls; you decide which ones each tenant uses and document who operates them.

​
Choose an operating model

​
Managed-operated

Choose this model when your team configures and supports communications for customers. The customer sees your branded service, while your operators provision workspaces, manage channels, and monitor usage. Use a sub-account for each customer. Set its logo, colors, dashboard name, support details, and custom domain. Start from a vertical bundle when an industry-specific baseline helps, then set the volume tier or rate card that matches your commercial terms. Verify before launch:
  1. Provision a sandbox sub-account and confirm that its data and API key are scoped to that workspace.
  2. Verify the custom-domain CNAME and load the branded sign-in page before inviting operators.
  3. Review the tenant’s consent, suppression, quiet-hours, and sender settings. The tenant owns these choices; do not assume a parent setting is the customer’s policy.
  4. Set a spend cap and test a usage line against the statement or rollup you use for reconciliation.
  5. If onboarding is automated through MCP, use an approved tool scope and record each provisioning result in your operations log.

​
Reseller sub-account

Choose this model when each customer operates its own workspace. You provide the branded account, pricing, and support boundary; the customer’s team sends, configures, and monitors its communications. Provision the child workspace with the white-label subaccounts guide. Give the customer a key minted for that sub-account, never the parent key. Configure branding and a custom domain through the child workspace, or let the child inherit the parent’s defaults when that is the tenant’s choice. Verify before launch:
  1. Test an allowed request with the child key and a request for a sibling or parent resource. The second request must fail the ownership boundary.
  2. Have the customer’s admin verify the logo, dashboard name, support contact, custom domain, and inherited-versus-overridden values.
  3. Run one sandbox channel test and confirm its delivery or call event appears in the correct workspace.
  4. Record who configures consent, quiet hours, sender registration, and suppression for this tenant.
  5. Suspend and reactivate a test workspace so your support team knows the customer-facing state for each transition.

​
OEM or embedded

Choose this model when your product is the primary application and communications is a capability inside it. Your application provisions or manages each customer’s workspace through an API or approved MCP operation; the customer may never open an Orbit-branded dashboard. Keep one sub-account per end customer. Bind every embedded action to the authenticated customer’s workspace and keep parent credentials server-side. Use branding and custom domains for any hosted operations surface that remains visible. Use vertical bundles to seed onboarding and volume tiers to make the commercial model predictable. Verify before launch:
  1. Reject a request when the authenticated customer and target workspace do not match.
  2. Give jobs and services credentials scoped to one customer instead of sharing a parent credential.
  3. Show the effective brand, domain, spending boundary, and communication settings before enabling production traffic.
  4. Audit provisioning, configuration changes, and automated tool actions.
  5. Test failed domain verification, missing senders, rate limits, and suspended workspaces; each should produce an actionable state in your product.
For the wider architecture decision, read Build vs Buy vs White-Label. For the mechanics of a resale program, see White-Label CPaaS models.

​
When not to white-label

Do not choose white-label when your customer needs a direct contract, independent carrier relationships, or control of the underlying network. A direct or build posture is a better fit when communications infrastructure itself is your differentiator. Do not consolidate customers into one shared workspace because they use the same industry bundle or rate card. A shared parent credential, shared export, or ambiguous support boundary creates an isolation risk. Keep each customer’s workspace and ownership checks explicit. Make tenant ownership clear for consent, suppression, quiet hours, sender registration, and related communication policies. If you cannot tell a customer who controls a setting and how they can change it, stop before production traffic.

​
Launch sequence

  1. Choose the archetype and name the operator, customer, and support boundaries.
  2. Provision a sandbox sub-account and verify credential and data isolation.
  3. Configure tenant-owned branding, custom domain, vertical bundle, and commercial controls.
  4. Run channel-specific tests and verify the resulting events in the correct workspace.
  5. Launch one customer, observe usage and support signals, and turn the checks into a repeatable runbook.
When moving an existing customer or service, use the migration playbook hub. It covers sandbox validation, consent and contact data, webhooks, parallel runs, and cutover. A branded dashboard alone is not a migration plan.