Should I use one VEC account per brand, or one shared account?

Last updated May 19, 2026Best practices

An agency managing email for five client brands, a holding company running three product lines, or a SaaS company with a marketing brand and a technical brand all face the same question: one Valid Email Checker account or several? In most cases, one shared account with separate API keys per brand is the right structure.

Why one shared account wins for most cases

  • Credit pooling. A shared Monthly plan covers all brands and absorbs spikes from any one of them. Per-brand accounts each carry their own buffer, which means the total credit reserve across all brands is much higher than the pooled equivalent. Pooling is cheaper.
  • One Stripe relationship. Single invoice, single card, single billing contact. Per-brand accounts mean tracking many subscriptions, many invoices, many renewal dates.
  • Per-brand attribution via API keys. Issue one API key per brand (named client-acme-prod, client-beta-prod, etc.). Credits History shows the key prefix on every charge, so you can attribute usage to a specific brand without separating the accounts. See should I use one API key per environment for the key-per-purpose pattern.
  • Unified dashboard and reporting. One login, one Credits History page, one place to set auto-refill. The team learns the platform once.

When per-brand accounts make sense

A small number of cases genuinely require separate accounts:

  • Legal entity separation. If the brands are owned by different legal entities (subsidiaries with independent finance), some compliance regimes require strict expense attribution. A single shared account complicates the chargeback paper trail.
  • Client invoice pass-through. Agencies that bill clients for verification credits as a passed-through cost sometimes prefer per-client accounts so the client sees their own invoice from us directly. Most agencies do not need this — the agency invoices the client with verification as a line item and absorbs the VEC bill internally.
  • Data segregation requirements. Healthcare and financial-services brands sometimes have explicit requirements that no operational data crosses entity boundaries. Per-brand accounts are the cleanest answer to those audits.
  • Different team-management needs. If brand A needs five team members and brand B should have only its single owner, account-per-brand makes RBAC simpler. (Though our team-management feature supports this within one account too.)

Practical structure for an agency

Most agencies converge on:

  1. One Valid Email Checker account in the agency name.
  2. Monthly plan sized to the aggregate verification volume across all clients.
  3. One API key per client (named to identify the client clearly).
  4. Internal billing reconciliation via the Credits History export, sliced by API key prefix.
  5. Client work isolated by API key but pooled at the credit level for cost efficiency.

Migrating from per-brand to shared

If you started with one account per brand and want to consolidate, the migration is mechanical: create the shared account, issue API keys per brand, switch each brand's calls to the new keys, then close the per-brand accounts. Existing Credits History on the old accounts stays as a historical record — see contact support if you need to coordinate the closure with refunds on unused PAYG credits.

For when to add team members vs opening a second account for internal team scale (rather than brand scale), see when should I add team members vs second account.