When a platform's transcription layer fails, the failure is rarely loud. A wrong name corrupts a CRM entry, a missed entity produces a misleading coaching score, and by the time the tenant flags it, the error has propagated through their downstream systems. For platforms reselling STT to hundreds of customer accounts, those silent errors compound at scale.
True white-labeling is not a UI exercise. It requires solving data isolation at the API key level, attributing consumption to individual accounts, and ensuring your infrastructure vendor's identity never leaks into your customers' workflows. This guide covers the full technical architecture for building a secure, compliant, and cost-predictable multi-tenant STT layer, with a direct comparison of the build-versus-buy trade-offs that every product leader at a CCaaS or voice platform eventually faces.
Scaling white-label STT through multi-tenancy
White-label STT means your customers interact with your product's name throughout the entire experience. That typically requires ensuring no vendor-branded elements surface across any customer-facing touchpoint in your platform. The deeper architectural challenge is ensuring data and billing stay separated across all accounts from day one.
The three pillars that determine whether a white-label STT layer works in production are: vendor identity isolation (no leakage into tenant-facing surfaces), per-tenant cost attribution (usage maps cleanly to individual accounts), and regional data routing (audio processes in the geography each tenant's compliance team requires).
Key requirements for white-label STT
The "bot identity" leakage problem is a specific failure mode: the infrastructure vendor's branding slips into customer-facing interfaces because the platform has not fully isolated the orchestration layer. This appears in meeting bot display names, webhook User-Agent headers, and calendar invites generated by recording integrations. Solving it requires complete control over how API credentials, bot identities, and notification templates are configured, all scoped to the platform layer, with no vendor defaults surfacing to end customers.
Beyond branding, clean metadata is critical. Transcription outputs should carry only tenant-defined identifiers, not provider-specific job IDs or model labels that a tenant's engineering team could reverse-engineer to identify the underlying vendor.
Attributing costs by tenant account
Usage-based pricing creates a margin calculation problem for resellers: the platform pays one aggregate bill but needs to allocate costs to individual customer accounts for accurate unit economics and downstream invoicing. The most reliable approach at scale is to combine per-tenant API keys with application-layer metadata tagging. Keys provide natural scoping for most of the attribution work, and tagged metadata handles the edge cases where multiple services share a key during a migration or testing phase.
Each key generates its own consumption trace, so platforms can pull hourly figures into their billing stack on any interval and apply their own margin before invoicing customers, without parsing a shared usage log after the fact.
Meeting regional data residency standards
Enterprise tenants in regulated industries require audio to be processed and stored in a specific geographic region. EU-based legal teams commonly require that voice data never leaves European infrastructure, which creates a hard dependency on your STT vendor's deployment topology. While contractual data processing agreements can address some transfer obligations under GDPR, the cleanest compliance posture routes audio exclusively through infrastructure in the required region.
Our infrastructure runs on EU-west and US-west clusters, and tenants can be routed to specific regions at the request level. For platforms serving customers across multiple geographies, that means one integration handles both regions without maintaining separate provider relationships or code paths. On Growth and Enterprise plans, we never use audio to retrain our models, and no opt-out action is required from the platform or its tenants.
Securing platform data via per-client keys
Per-client API key issuance is the foundational technical control for any multi-tenant deployment. It ensures that a credential compromise at one tenant does not affect others, that usage data is naturally scoped to the correct account, and that access revocation is atomic rather than requiring platform-wide key rotation.
The architecture follows a consistent pattern: the platform's API gateway receives a request carrying the tenant's session context, a tenant router middleware maps that context to a key scoped to that account, the request routes to our processing cluster with no cross-tenant data visibility, and the response returns via a webhook endpoint registered for that tenant specifically.
Automating per-tenant key lifecycle
Key provisioning should trigger automatically on tenant onboarding. The workflow looks like this:
- Tenant creation event: The platform's backend fires a webhook or internal event when a new customer account activates.
- Key provisioning: The platform calls our API to generate a new key scoped to that tenant, stores it in a secrets manager, and associates it with the tenant record.
- Rotation schedule: Rotate keys on a fixed interval or on-demand after a security event, activating the new key before the old one expires to avoid downtime.
- Revocation: On tenant offboarding, the platform calls the revocation endpoint immediately, cutting access without delay.
Our Python and JavaScript SDKs support key generation and revocation calls, which keeps the provisioning logic lean and the onboarding workflow entirely within your own control plane.
Preventing cross-tenant data leaks
The fundamental architectural rule is that a tenant's API key must only ever return data associated with jobs submitted using that key. Shared-schema database designs that distinguish tenants by a column value create risk: a query bug can return rows across tenants without triggering an authentication failure. Key-scoped isolation at the infrastructure layer significantly reduces this class of bug by making cross-tenant access require a credential mismatch, not just a query oversight, though consistent enforcement across identity, token issuance, and data access layers is still required at the application level.
Speaker diarization, which identifies individual speakers across a recording, is async-only and powered by pyannoteAI's Precision-2 model. That means no diarization output is generated in real time, and every diarized transcript returns exclusively to the key that submitted the job.
Customizing STT for specific tenants
Platforms serving different customer verticals can apply per-tenant configurations without maintaining separate codebases. The three most common customization requirements are:
- Custom vocabulary: Tenant-specific product names, acronyms, and domain terms that generic models would likely misrecognize. Our custom vocabulary support lets platforms define term lists per request.
- Model selection: Solaria-3 for European business audio across EN, FR, DE, ES, and IT, where it ranks #1 on Switchboard, the most challenging dataset, ahead of AssemblyAI, Mistral, Speechmatics, ElevenLabs, and Deepgram. Solaria-1 covers broad multilingual coverage across 100+ languages including real-time streaming.
- PII redaction: Our PII redaction feature replaces sensitive entities like names and phone numbers with placeholder tokens in the transcript output. This requires explicit configuration per request and is never enabled by default.
Monitoring per-tenant transcription volume
Standard uptime monitoring is not sufficient for detecting transcription quality degradation. A STT service can be fully operational at the infrastructure level while a specific tenant's audio produces elevated word error rates due to codec changes, background noise shifts, or speaker demographic drift. Platforms need tenant-scoped observability, instrumented at the integration layer, that tracks quality metrics, not availability alone.
Tracking consumption and setting alert thresholds
Track three metrics per tenant: audio hours processed, concurrent streams in flight, and average processing latency per job. These figures feed the billing attribution logic and provide an early signal when a tenant's usage pattern changes in ways that could indicate a quality regression or an unexpected cost spike.
Per-key usage data makes this straightforward because every request carries the tenant identifier implicitly. Consider setting rate-based alerts when a tenant approaches their contracted volume limit or shows an unusual spike in hourly consumption to catch concurrency ceiling breaches or integration misconfigurations before they affect SLAs or invoices. The optimal alert structure varies depending on whether tenants run real-time or async workflows.
Calculating unit costs per tenant
Here is how per-hour pricing maps to tenant-level cost attribution across three representative volume tiers:
| Monthly volume |
Async rate |
Monthly cost |
Per-tenant cost (÷ 100 accounts) |
| 100 hours |
$0.61/hr (Starter) |
$61 |
$0.61 |
| 1,000 hours |
As low as $0.20/hr (Growth) |
$200 |
$2.00 |
| 10,000 hours |
As low as $0.20/hr (Growth) |
$2,000 |
$20.00 |
All figures include diarization, translation, named entity recognition, sentiment analysis, and custom vocabulary at no additional charge on Starter and Growth plans. Growth plan rates start from $0.20/hr at higher commitment levels. The effective rate for lower-volume tenants will be higher.
Automating multi-tenant billing
Emit a metering event for each completed transcription job, tagged with the tenant ID and audio duration, and pipe it into billing platforms like Stripe or Lago via your platform's metering layer. The billing platform aggregates those events on the billing cycle and generates the customer invoice automatically. Our audio intelligence pipeline returns audio duration in the response payload for every job, so the metering event can be emitted from the same webhook handler that processes the transcript.
Designing secure multi-tenant access models
A secure multi-tenant STT platform separates access across distinct tiers, with elevated platform credentials kept strictly isolated from tenant-facing accounts, and each tenant's users limited to submitting audio and retrieving transcripts scoped to their own session. These boundaries should be enforced at the API layer, not just the UI layer.
Enforcing tenant-isolated permissions
Tenant admins must not be able to see or modify another tenant's configuration, and individual users must access only transcripts associated with their own session tokens. At the backend layer, every database query from a tenant context must include a tenant ID filter derived from the validated server-side session, not from client-supplied parameters. This prevents tenant impersonation attacks where a malicious user modifies a request to access another account's data, and it enforces isolation at the query layer regardless of what the application logic above it does.
Audit logging for multi-tenant compliance
Immutable audit logs are a hard requirement for enterprise customers in regulated industries. Every log entry must record the tenant ID, the user who submitted the request, the audio file identifier, the timestamp of submission and completion, and the transcript output identifier. You must store these logs append-only and separately from the application database to prevent tampering.
Enterprise tenants in financial services and healthcare will request these logs during security reviews. Our compliance hub covers what our SOC 2 Type II audit scope includes, which informs what you can claim about your own compliance posture when your STT layer runs on our infrastructure.
Guaranteed performance for tenant transcriptions
Platforms must align their customer-facing SLAs with their infrastructure vendor's performance guarantees. If a vendor's SLA covers uptime but does not include latency or accuracy commitments, the platform absorbs the quality risk on its own.
Aligning SLAs for multi-tenant resale
We publish our uptime history publicly. Aircall processes over 1 million calls per week through our API, and a fintech customer runs 800 concurrent sessions, which represents the scale at which these commitments have been tested in production. Platforms can anchor their own customer SLAs to these figures when the customer-facing commitment matches the infrastructure's verified track record.
Configuring rate limits for tenants
Granular rate limiting per tenant key prevents the "noisy neighbor" problem where a single tenant's traffic spike degrades processing quality or availability for all other accounts. Set concurrency limits per key that reflect each tenant's contracted volume, a pattern common across contact center platforms that handle burst traffic from call center peaks without over-provisioning idle capacity, and implement queue depth monitoring so you can detect when a tenant is approaching their limit before they hit it.
Managing multi-tenant regional uptime
Multi-region deployment provides geographic data residency for compliance and failure isolation so an incident in one region does not affect tenants routed to the other. Disaster recovery in this architecture means routing tenant traffic to an alternate region at the DNS or load balancer level, with each tenant's key and configuration synchronized across regions in advance. For cross-continental failover scenarios, confirm data transfer mechanisms comply with your tenants' regulatory requirements.
Verifying SOC 2 and ISO certifications
Enterprise security reviews require evidence, not assertions. Our certifications cover SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance, all available through our trust documentation. Reference these certifications in your own vendor questionnaire responses when customers ask about the underlying infrastructure. For HIPAA-regulated customers, a Business Associate Agreement (BAA) is required before any protected health information is processed, and this must be in place at the platform level for the compliance chain to hold. We run exclusively on dedicated cloud clusters across EU and US regions. On-premises or air-gapped deployment is not available on any plan, which is a hard disqualifier for regulated tenants whose security requirements mandate fully isolated on-prem infrastructure.
Customizing the multi-tenant STT experience
Different customer segments need different transcription configurations, and a configuration layer that maps tenant attributes to API request parameters lets the same integration code handle all customer types without maintaining separate codebases.
Tenant-specific domain configuration
Platforms can route webhook delivery and API requests through custom, tenant-branded domains (configured via CNAME or proxy layer) to keep the end-customer experience consistent with your platform's brand identity and enforce geographic routing rules at the DNS level for data residency compliance.
For voice AI and contact center platforms serving global customers, this custom domain configuration also avoids exposing infrastructure naming conventions in logs that tenants can access.
Managing webhooks at scale
To maintain webhook reliability at scale, implement retry logic with exponential backoff, a dead-letter queue for permanently failed deliveries, and idempotency keys on every event so duplicate deliveries from network retries do not cause duplicate processing.
Designing consistent API fault codes
Map all STT-layer error codes to a clean, standardized error taxonomy that your platform exposes to tenants. Tenants must not receive raw error messages that identify the underlying vendor, reveal implementation details, or require them to understand the vendor's error schema to diagnose problems. A well-designed fault code layer also makes it possible to swap the underlying STT vendor in the future without changing the interface tenants integrate against.
Build vs. buy for multi-tenant STT
The build-versus-buy decision for multi-tenant STT infrastructure is ultimately a question of total cost of ownership across a three-year horizon, not upfront integration cost alone.
Build vs. buy decision matrix
| Dimension |
Managed API (Gladia) |
Custom build |
Self-hosted Whisper |
| Setup cost |
Sub-24hr to production |
Engineering investment required |
GPU provisioning + engineering effort |
| Multi-tenant isolation |
Per-key by design |
Custom middleware required |
No built-in tenancy |
| Maintenance overhead |
Minimal |
$240K–$480K/yr in dedicated engineering (3–6 FTEs) |
$240K–$480K/yr in dedicated engineering (3–6 FTEs) + GPU ops |
| Compliance certifications |
SOC 2 Type II, ISO 27001, HIPAA, GDPR |
Platform's own responsibility |
Platform's own responsibility |
| Time to market |
Days |
Weeks to months |
Variable |
| WER on real-world audio |
Accurate on noisy, accented, and multilingual production audio |
Depends on model choice |
Higher on noisy or accented audio |
Self-hosting only becomes cost-effective at high sustained volumes, once dedicated DevOps maintenance, GPU idle costs during off-peak hours, and the engineering time required to build tenant isolation, key rotation, and billing attribution from scratch are all priced in. Accuracy on production recordings can degrade with noisy or accented audio because open-source models trained primarily on clean speech do not handle telephony codecs, regional accents, or code-switching at the same level as models purpose-built for those conditions. Teams that move off self-hosted setups report saving 20%+ DevOps effort and eliminating the ongoing maintenance cycle entirely.
Deepgram and AssemblyAI both now offer dedicated voice agent APIs and application-layer products that compete directly with the CCaaS and meeting assistant platforms they serve as infrastructure partners. We have publicly committed to remaining a pure-play audio infrastructure provider and not building products at the application layer above our API.
Per-client key management and reporting
Per-client key generation, revocation, and consumption reporting are all available through the API, which keeps the tenant onboarding workflow entirely within your own control plane.
"Accurate, fast and developer friendly transcription API for multilingual audio" - Faes W. on G2
The integration speed advantage compounds on multi-tenant platforms because every week saved on infrastructure setup is a week the engineering team can spend on the differentiated features that drive customer retention.
GDPR-compliant infrastructure stack
Our EU headquarters and multi-region deployment mean that platforms serving European enterprise customers can provide a credible data sovereignty guarantee backed by infrastructure architecture, not just contractual language. On Growth and Enterprise plans, we never use customer audio for model training, and no opt-out configuration is required. This matters specifically for contact center platforms where audio contains sensitive customer conversations that tenant legal teams will scrutinize.
Gravite, a French CCaaS quality-monitoring platform, achieved a 93% reduction in review time while processing 50,000 hours of audio per year on our infrastructure. Their deployment required French-first accuracy, European data sovereignty, and zero fallback provider dependency, all of which we provide without additional configuration overhead, including the data governance documentation that enterprise tenants will request during security reviews.
How platforms validate STT performance
Static vendor benchmarks on curated datasets do not predict performance on your customers' audio. The characteristics that matter for production accuracy on a contact center platform, including telephony codecs, non-native speakers, overlapping speech, and domain-specific terminology, are systematically underrepresented in public benchmark datasets. Our async benchmark methodology evaluates Solaria-1 against 8 providers across 7 datasets and 74+ hours of audio, showing on average 29% lower WER on conversational speech and 3x lower DER vs. alternatives, and the methodology is open and reproducible.
For your own audio, our blind comparison tool is a fun way to test providers on your audio by removing the brand bias and lets you test files across six providers with ELO-ranked results. The leaderboard reflects real community-submitted audio rather than vendor-selected test conditions, and the test methodology is fully transparent, including a walkthrough of how output quality varies across providers on real-world audio conditions.
For teams evaluating key data extraction accuracy specifically, names, account numbers, and product codes, test on recordings from your actual tenant base before committing to any infrastructure decision.
Start with €50 in free credits and have your multi-tenant integration in production in less than a day.
FAQs
How do platforms maintain tenant privacy in multi-tenant STT?
Assign a unique API key to each tenant at account creation so all audio submissions, transcripts, and usage data are isolated by credential rather than relying on query-level filtering. On Growth and Enterprise plans, customer audio is never used for model training, and Enterprise plans support zero data retention after processing.
How do you set granular rate limits per tenant key?
Rate limits apply at the key level, so each tenant key carries its own concurrency ceiling and hourly volume cap. Configure these limits to match each tenant's contracted allocation and consider setting threshold alerts before tenants approach the hard limit so platform operators can respond proactively.
How do you handle data residency for multi-tenant deployments?
Specify the target region (EU-west or US-west) in the API request parameters to route each tenant's audio processing to the appropriate cluster. Audio processing and storage can be kept within the designated geography by specifying the target region in each API request. This addresses GDPR requirements for EU-regulated enterprise tenants, though teams should verify their specific data residency obligations with legal counsel.
How can platforms track SLA performance by tenant?
Log job submission timestamp, processing completion timestamp, and audio duration for every transcription job tagged with the tenant ID. Aggregate these records per tenant to calculate average processing latency, throughput, and uptime against each tenant's contracted SLA, and expose the results through a tenant-facing dashboard or automated report built on top of per-key usage data.
Key terms glossary
WER (Word Error Rate): The primary metric for transcription accuracy. Calculated by dividing the total number of word-level errors (substitutions, deletions, and insertions) in a transcript by the total number of words in the reference, expressed as a percentage. Lower WER indicates higher accuracy.
DER (Diarization Error Rate): A metric that measures the accuracy of speaker attribution in a multi-speaker recording. DER is calculated by comparing the system's speaker segment boundaries and labels against a human-annotated reference, expressed as a percentage of total audio duration incorrectly attributed.
CCaaS (Contact Center as a Service): A cloud-based model for delivering contact center functionality (call routing, recording, transcription, and quality monitoring) as a managed service. Platforms built on CCaaS infrastructure typically resell STT as a component of a broader customer engagement product.
Code-switching: Mid-conversation language changes, where a speaker shifts between two or more languages within a single audio recording or utterance. Accurate transcription of code-switched audio requires a model trained to detect and handle language transitions without treating the alternate language as noise.
Data residency: A requirement that data be stored and processed within a defined geographic boundary, typically mandated by regulation (GDPR, for example) or enterprise policy. Distinct from data sovereignty, which concerns legal jurisdiction over data regardless of physical location.
GDPR (General Data Protection Regulation): The European Union's primary data protection regulation, governing how personal data of EU residents is collected, stored, processed, and transferred. Applies to any organization handling EU resident data regardless of where the organization is headquartered.
Idempotency key: A unique identifier attached to an API request or webhook event that allows the receiving system to detect and safely ignore duplicate deliveries. Prevents double-processing when network retries cause the same event to arrive more than once.
PII (Personally Identifiable Information): Any data that can be used to identify a specific individual, including names, phone numbers, email addresses, and account numbers. Handling PII in audio transcription workflows triggers data protection obligations under GDPR, HIPAA, and comparable regulations.
SOC 2 Type II: An audit report that evaluates whether a service organization's security controls (covering security, availability, processing integrity, confidentiality, and privacy) operated effectively over a defined period, typically six to twelve months. Type II is a higher assurance standard than Type I, which only assesses control design at a point in time.
Speaker diarization: The process of segmenting an audio recording by speaker identity, answering "who spoke when" across the transcript. Accuracy is measured by DER. Diarization is an async-only capability. It is not available for real-time streaming workflows.
