Retell AI for Agencies: One Account or One Per Client? How to Structure Accounts, Keys and Phone Numbers

Disclosure: I'm Nabeel, founder of VoiceDash, a client portal for Retell agencies. This post is about account design, not the product.

If you build Retell AI agents for more than one business, you hit a design question long before you hit a scaling problem: does every client live in one Retell account, or does each client get their own? It looks like a billing choice. It is really a tenancy choice, and it decides how you attribute cost, how far a leaked API key can reach, who owns the phone numbers, and how messy offboarding gets.

TL;DR: run one agency account for clients on a managed retainer, where you carry the usage and bill a flat fee, and use a client-owned account only when the client insists on owning the vendor relationship, works in a regulated industry that wants its own agreements, or is big enough to want its own billing. Whichever you pick, decide four things up front: who pays Retell, who owns the numbers, how agents are named and tagged per client, and what the client gets to see. I build production voice agents for US clients on Retell, n8n, GoHighLevel and Twilio. Here is how I structure it.

Why account structure matters more than it looks

Nobody thinks about account structure on client one. You sign up for Retell, build an agent, buy a number, and ship. By client five you have a single account holding five businesses' agents, numbers, recordings and transcripts, all paid for on your card, all reachable with one API key.

That setup creates four real problems as you grow:

• Cost attribution. Retell bills per minute, and the bill arrives as one number. If you cannot split minutes by client, you cannot tell which retainer is profitable.
• Access and data isolation. Anyone with access to the account, a contractor or a new hire, can see every client's calls. Clients themselves can never be given that login.
• Ownership disputes. When a client leaves, the question "whose phone number is this and who keeps the recordings" needs an answer you agreed in writing, not one you invent on the day.
• Blast radius. A failed payment, a leaked key or a rate limit on one account touches every client at once.

None of this means one account is wrong. It means one account needs rules.

Option 1: One agency account for all clients

This is what most agencies run, and what I recommend for the managed retainer model.

How it works. You own the Retell account and the payment method. Every client's agents live in it. You pay Retell for all minutes and charge each client a flat monthly retainer that covers usage up to an agreed level.

Why it works.

• One place to build, test and update every agent, which matters when you roll the same fix across ten clients.
• One integration setup for n8n, GoHighLevel or your own middleware.
• Your margin stays private. The client sees what their agent did, not what it cost you.
• Onboarding is fast because nothing new has to be created on the client's side.

What it needs to stay sane.

• A strict naming convention. I prefix every agent with the client code, for example ACME-receptionist-v3, so nothing is ambiguous in logs, webhooks or reports.
• Per-client metadata on every call, passed in from the phone number or the agent, so post-call data can be split by client. Retell's call metadata and post-call analysis are what make this reliable; I wrote up the fields I use in Retell AI Post-Call Analysis: The Fields I Set Up on Every Client Agent.
• Usage tracked per client every month, even if you bill flat, so you notice when one client's volume quietly eats the margin.
• A client-facing layer that is not the Retell dashboard. Clients must never log into the shared account. More on that below.

Option 2: A separate Retell account per client

How it works. Each client has their own Retell account, usually with their own card on it. You get access to build and maintain the agent, and the client pays Retell directly for minutes. You charge a management fee on top.

When I use it.

• The client wants to own the vendor relationship. Some owners, especially those who have been burned by an agency before, want the account, the card and the data in their own name.
• Regulated industries. A medical practice or law firm may want its own agreements with each vendor rather than routing through yours.
• High or unpredictable volume. Outbound campaigns and large multi-location groups can swing usage enough that carrying it on your card is a real cash flow risk.
• The client plans to take it in-house eventually, and you are being paid to build and hand over.

The costs. Every client account means a separate setup, separate API keys to manage, separate webhook configuration and separate places to check when something breaks. Updates that take minutes across one account become a checklist across ten. You also lose the clean flat retainer, because the client now sees the raw per-minute bill and will compare it to your fee.

The hybrid I actually run

In practice I end up with a mix:

• Managed retainer clients live in the agency account. That is the majority.
• Clients who insist on ownership or need their own agreements get their own account, and I document my access in the contract.
• Pilots always start in the agency account, so I can test fast without asking a prospect for a card. If the client converts and wants their own account, migrating the agent is a planned step, not a surprise.

The rule that makes the hybrid work is writing the choice down at onboarding, in the same intake where you collect hours, services and escalation contacts.

Phone numbers: decide ownership before you buy one

Phone numbers cause more offboarding fights than anything else, so I treat them separately from the account question.

• Numbers bought inside the agency account belong to the agency account. If the client prints that number on their trucks, you have created a dependency they did not agree to.
• The client's main business line should stay theirs. Forward to the agent or route through a carrier the client controls, rather than porting their main number into your account.
• Tracking or campaign numbers you buy for a client should have a written rule: they port to the client on exit, or they are released.

Recordings, transcripts and offboarding

Call data lives where the account lives. In a single agency account, every client's recordings and transcripts sit in your account, which is good for support and bad if you have not agreed retention and export rules.

What I put in writing for every client, whichever structure:

• How long recordings and transcripts are kept, and who decides.
• What the client receives when they leave: an export of their call history, their prompt and configuration if the contract says so, and their numbers ported or released.
• How quickly you delete their data from the agency account after exit.

Offboarding cleanly is also a sales point. Telling a prospect exactly how they can leave makes them more comfortable signing.

API keys and access hygiene

A shared account is only as safe as its access rules.

• Keep the key server side. Never put a Retell API key in a client-facing tool, a shared spreadsheet or a no-code step that clients can open.
• Limit who can log in. Contractors get access for the work they are doing, and lose it when they finish.
• Rotate keys when someone leaves or a key may have been exposed, and know in advance which integrations will break when you do.
• Monitor all clients, not just the loud ones. One account means one place to watch for failed calls.

What the client sees: never the raw account

Whichever structure you choose, the client should not be working inside Retell. Retell's dashboard is built for builders: agents, prompts, settings, and in a shared account, every other client's calls. Even in a client-owned account, the raw dashboard shows cost and configuration the owner does not need to see.

So the client-facing layer is a separate, tenant-scoped read model: calls synced from the API or webhooks, keyed by the client identifier you put in metadata or the agent prefix, and every query filtered by that tenant before anything renders. Whether you build that yourself or use an off-the-shelf portal, the account design above is what makes it possible. If agent names and call metadata are not consistent, no reporting layer can split the data cleanly afterwards.

The account structure checklist

• Default structure chosen: agency account for managed retainers, client account by exception
• Reason for any client-owned account written into the contract
• Agent naming convention with a client prefix, applied to every agent
• Client identifier passed into every call for usage and reporting splits
• Monthly usage reviewed per client, even on flat pricing
• Phone number ownership and exit rule agreed before buying any number
• Recording retention, export and deletion terms in writing
• API keys server side only, access limited, rotation plan known
• Monitoring covering every client in the account
• A scoped client view in place, so no client ever logs into Retell

The bottom line

Structure your Retell setup on purpose before client five forces it on you. One agency account is the right default for a managed voice AI agency because it keeps building fast and your margin private, as long as you name agents by client, split usage by client, agree ownership of numbers and data up front, and give every client their own scoped view instead of the raw account. Use client-owned accounts when ownership, regulation or volume genuinely call for it, and write that choice down.

Drafted with AI assistance and fact-checked against each vendor's docs.