Multi-Tenant Setups in Vapi: Key Security and Cost Tracking

Dominik Keller

Apr 29th, 2026

Blog

Vapi API Key Security: A Guide to Multi‑Tenant Setups and Cost Tracking

You’ve built a brilliant voice agent with Vapi. The prompt is polished, response times are human-like, and the AI handles edge cases like a pro. Your client wants it embedded on their website. You drop in the Vapi Web SDK snippet, replace YOUR_PUBLIC_API_KEY, and push it live. The widget works perfectly.

Then you open Chrome DevTools, glance at the Network tab, and your stomach drops. There’s your public API key – sitting in plain sight, readable by anyone who visits the page! Could someone copy that key and rack up thousands of dollars in calls from a rogue domain? How do I bill this client for their usage without also paying for everyone else’s? And when I onboard my next client, how do I keep their data and costs completely separate?

This is the API key security and multi‑tenancy gap that hits every voice AI agency. Vapi gives you the keys (literally) to build an agent, but securing those keys for client delivery, and tracking costs per client, requires architecture that Vapi doesn’t spell out in the QuickStart guide. In this post, I’ll walk you through that architecture: from key types and origin restrictions to per‑organization billing and the proxy pattern that locks everything down.

By the end, you’ll have a production‑ready model for delivering Vapi voice agents to multiple clients securely, with accurate per‑client cost tracking – and I’ll show you how Five automates the whole thing.

The Two‑Key System: Public vs. Private API Keys

Vapi provides two types of API keys, and understanding the difference is the foundation of a secure multi‑tenant setup:

Public key — Designed to be used in client‑side code. It can create calls and websocket connections, but it cannot read assistant configurations, modify settings, or access billing. It’s meant to be exposed, but that doesn’t mean it should be unrestricted.
Private key — Used for server‑side operations: creating and updating assistants, pulling analytics, managing phone numbers, and retrieving cost data. This key must never touch a browser.

The naive approach, i.e. using a single public key for all clients, is the security equivalent of leaving your front door unlocked. Yes, the public key is limited, but without additional restrictions, anyone who grabs it from your client’s website can spin up calls from any domain, exhausting your account balance. Worse, because all usage flows through one key, you have no way to know which client generated which costs.

The solution: per‑client public keys, scoped to specific domains, associated with unique organizations.

Multi‑Tenancy with Organizations: Isolating Clients

Vapi’s Organization (Org) model is the foundation for multi‑tenancy. Each organization is a separate workspace with its own assistants, phone numbers, knowledge bases, and — critically — its own API keys and usage logs.

For an agency, the pattern is:

Your master Org — Where you build and test agents. Private key only, never shared.
Client‑specific Orgs — Created for each client you serve. Each Org gets its own public (and optionally private) keys, plus its own set of assistants.

When you move to production, you generate a unique public API key inside the client’s Org. That key is then embedded in their widget. The result: Client A’s calls are completely isolated from Client B’s. Client A’s key has no access to Client B’s assistants, call logs, or billing data.

This is the “container” model that agencies ask about constantly. It takes a few steps to implement manually, but it’s straightforward once you understand Vapi’s hierarchy:

Master Account
 └─ Org: Your Agency (private key only)
 └─ Org: Client A
 │   └─ Public Key: "pk_client_a_..."
 │   └─ Assistant: "Receptionist - Client A"
 │   └─ Phone Number: +1 (555) 100-1001
 └─ Org: Client B
     └─ Public Key: "pk_client_b_..."
     └─ Assistant: "Booking Bot - Client B"
     └─ Phone Number: +1 (555) 200-2002

Locking Down Public Keys with Allowed Origins

A per‑client public key is a huge step forward, but without origin restrictions it’s still vulnerable. Someone could copy Client A’s public key and embed it on their own site, using your client’s account to handle calls for free.

Vapi lets you bind a public API key to a list of Allowed Origins. These are the domains (and ports) from which the key can be used. If a call‑creation request arrives from a domain not on the list, Vapi rejects it.

To set this up when generating a public key:

Navigate to the client’s Organization in Vapi.
Create a new Public API Key.
Under Allowed Origins, add the exact domains that will host the widget — e.g., https://www.client-a-website.com, https://app.client-a-website.com.
Save the key and embed it in the client’s widget code.

Now, even if the key is leaked, it’s useless on any other domain. This is the standard technique recommended by Vapi and by experienced agency developers exploring “customer‑specific public API keys that can be tied to allowed origins.”

For developers who need to test on localhost, you can temporarily add http://localhost:3000 to the allowed origins during development and remove it for production.

Per‑Client Cost Tracking: Using OrgIDs to Calculate Charges

The security piece solved, the next question is always billing: “How do I calculate the charge for that specific API key?”

The answer lies in the Organization ID (OrgID) associated with each key. Vapi tracks usage per Organization, and you can pull that data through the dashboard or the API to build per‑client invoices.

Step 1: Retrieve Usage Per Org

Using Vapi’s Analytics API, you can fetch call logs filtered by OrgID. A call to the reporting endpoint returns data that includes:

Total calls in the date range
Total minutes (broken down by provider)
Costs for orchestration (Vapi’s per‑minute fee), STT, TTS, LLM, and telephony

If you’re using the Vapi dashboard, navigate to the client’s Org, go to Analytics, and you’ll see a cost breakdown for that Org alone.

Step 2: Calculate Client‑Facing Charges

You’re not just passing through Vapi’s cost — you’re running a business. You’ll add your markup to the underlying costs. The real‑world all‑in cost for a Vapi call lands between $0.23 and $0.33 per minute when you sum orchestration, Deepgram/Whisper transcription, OpenAI/Anthropic LLM, ElevenLabs/Play/TTS, and Twilio/Vonage telephony.

A common agency pricing model:

Pass‑through plus margin: Multiply total Vapi cost by 1.3‑1.5x
Flat per‑minute rate: Charge $0.40/minute regardless of underlying cost
Tiered subscription: $299/month for up to 1,000 minutes, then $0.35/minute overage

With per‑Org usage data, you can run the numbers at the end of each billing cycle and generate a Stripe invoice. No more manual spreadsheet detective work.

Step 3: Automate, Don’t Hunt for Data Monthly

Doing this manually across 10+ clients is soul‑crushing. Every month you’re logging into Vapi, switching Orgs, exporting CSVs, calculating totals, and manually creating Stripe invoices. It’s the kind of repetitive work that prevents agencies from scaling.

The long‑term solution is a system that pulls per‑Org analytics automatically, applies your pricing model, and generates invoices in Stripe. That’s exactly what the Five white‑label Vapi portal does.

Advanced Security: The Proxy Server Pattern

For agencies with the highest security requirements, there’s one more pattern worth knowing: proxy all client calls through your own server.

Instead of embedding a Vapi public key in the widget at all, you:

Build a lightweight backend endpoint on your own server.
Store the Vapi public key only on the server, never in client‑side code.
The client’s website sends call‑creation requests to your endpoint.
Your server validates the request, authenticates the client session, and forwards the call creation to Vapi using the appropriate per‑Org key.

The result: the end‑user’s browser never sees a Vapi API key. It’s the most secure approach, and it also opens the door to additional value — like logging, custom analytics, and per‑call business logic — before the call even starts.

The tradeoff is latency and complexity. You’re introducing a hop between the user and Vapi’s infrastructure. For most agencies, properly restricted per‑Org public keys with allowed origins provide sufficient security without the overhead.

Build Secure Multi‑Tenant Voice Apps Without the API Key Headache

You’ve seen the architecture. You know the patterns. Now let’s get you running with it — without the months of build time. Check out our white-label Vapi portal to secure your Vapi agents properly.

Request a Trial — We’ll spin up a dedicated Five instance.
Connect Your Vapi Account — Your assistants and phone numbers sync instantly.
Onboard a Client — Five provisions the user credentials automatically.
Go Live — Your client gets a branded portal, accessible only from their domain, with zero Vapi‑branded surfaces.

Stop guarding API keys and start scaling your voice AI business.