White-label live streaming for resellers: per-customer domains, isolation and usage billing

Updated 2026-10-11

A reseller, agency or group brand that runs live video for many customers needs each of them to look and behave like a separate service: their own domain in the player URL, their own stream names, their own protection rules, and a bill that matches what they actually used. This guide shows how Streaming CDN models that, and what the setup looks like for one new customer.

The model: one workspace per customer

Stream names never collide

Every ingest domain is an independent namespace, so two customers can both publish a stream called main without touching each other. A customer with several ingest domains, for example one per event or per brand, gets one namespace per domain as well.

A playback domain plays the streams of the ingest domain it is bound to. Several playback domains can be bound to the same ingest domain, for example one per partner site, each with its own allowlist and policy, and a playback domain can be re-bound later without changing the encoder.

Customer A
  push.customer-a.com   (ingest)    ->  stream "main"
  live.customer-a.com   (playback, bound to push.customer-a.com)

Customer B
  push.customer-b.com   (ingest)    ->  stream "main"   (a different stream)
  watch.customer-b.com  (playback, bound to push.customer-b.com)

Domains on the customer's own DNS

1. Add the domain in the customer's workspace and choose ingest or playback (a playback domain also picks its ingest domain).
2. The console shows one CNAME record. The customer, or you on their behalf, creates it at their DNS provider.
3. The platform issues and renews the TLS certificate. The console shows the domain's DNS and certificate status, and the domain becomes usable only when both are active, so a half-configured domain never serves viewers.
4. Publish from OBS over WHIP to https://push.customer-a.com/live/main and watch at https://live.customer-a.com/live/main.

Browsers only allow camera and microphone on secure origins, which is one more reason the certificate has to be active before a domain is used for publishing from a web page.

Protection per customer

Because protection is set on each domain, a customer that embeds the player on one site can lock playback to that site's origin, while another customer that sells tickets can require signed playback URLs. Stream Keys are created per ingest domain and shown once; publisher IP allowlists stop anyone else from publishing into the customer's namespace.

Billing by actual usage

• Usage is recorded per customer, per stream and per domain, so a customer's bill can be broken down the same way.
• A reseller account sees all of its customers, opens new customer workspaces with just an email address, and gets a monthly statement of its customers' usage for settlement.
• Customers under a reseller pay through the reseller, not by card on the platform, so the commercial relationship stays with you.
• Request logs record every playback and publish and export as CSV, which helps answer a customer's "why is my bill higher this month".

Checklist for a new customer

1. Create the customer's workspace with their admin's email address.
2. Add an ingest domain and a playback domain bound to it; have the customer create the two CNAME records.
3. Wait until both domains show DNS and certificate active.
4. Turn on Stream Key authentication and create a key for the encoder; add the publisher's public IP if it is fixed.
5. Set the playback protection the customer needs: allowed origins, signed URLs, request-source policy (start in log mode).
6. Publish a test stream and confirm it plays on the customer's playback domain and appears in their usage.