Managing client stores

Running Evident across a portfolio — organizations, access, billing, and the things that scale badly if you set them up wrong.

6 min read

On this page

An agency running Evident for several merchants is a different shape of problem from a merchant running it for themselves. Most of the decisions that matter are made once, at the start, and are painful to change later.

One organization per client

Do not put six clients’ stores in one organization.

An organization is the boundary for billing, team membership, API keys and the security audit log. Sharing one across clients means every client’s data is reachable by everyone with access, one invoice covers all of them, and handing a client their account back means extracting a store from a shared container.

One organization per client, with their stores inside it. That way a handoff is a change of ownership rather than a migration.

Your team’s access

Your address can belong to any number of organizations with a different role in each. Your email is unique within an organization, not globally — which is what makes this work.

In practice: sign in, and if your address matches several organizations you get a picker. Which account you land in is always a choice; Evident will not infer an organization from an email address.

Give your people the narrowest role that lets them work:

  • Owner — you, and probably nobody else. Billing and account deletion.
  • Admin — anyone configuring connections, keys or email.
  • Member — moderation, FAQs, galleries. Most of your team, most of the time.

Billing

Two arrangements:

  • The client pays. Their organization, their subscription, their card. You have access; you do not have the invoice.
  • You pay. Agency billing is set per client organization — the client’s subscription is paid by you and they see no billing tab.

Agency billing is gated on the billing relationship itself, not on you holding a seat, so it survives your staff changing.

If you resell, be aware that a partner-created client organization shares one billing customer with your other clients. Invoice scoping does not currently separate cleanly per client. If you need a per-client invoice to pass through, check what the invoice actually shows before you promise it.

Feature toggles per store

Turn off what a client does not use, per store. Reviews-only on five stores and the full stack on the sixth is a normal configuration.

This is not the same as a plan limit: a toggle hides the feature, a plan lock leaves it visible with a padlock. Hiding something a client could buy means they will never ask for it — which is fine if they genuinely do not want it, and a lost upsell if you switched it off to tidy the menu.

Onboarding a client, in order

  1. Create the organization, or have the client create it and invite you.
  2. Connect the store. Get the scopes right the first time — this is the step that is expensive to redo. On BigCommerce, a manual API account’s scopes are immutable, and reconnecting with new credentials creates a duplicate store rather than upgrading the existing one. Prefer the app.
  3. Import history before configuring anything else, so product pages are never empty.
  4. Authenticate a sending subdomain on the client’s domain, not yours.
  5. Install and theme the widgets on staging.
  6. Configure the sequence, one step plus a reminder.
  7. Hand over access and agree who moderates.

Step 2 is where portfolio-scale pain comes from. A client connected without the loyalty coupon scope will look fine for months and then fail the first time someone redeems.

Handing a store back

The clean version: the client’s organization already exists, with their own owner in it. You remove your team’s memberships and, if you held billing, they take over the subscription.

If you skipped the one-organization-per-client rule, this is instead a data migration. Which is why the rule is first on this page.

API keys across a portfolio

Keys are bound to one organization. There is no cross-client key and no cross-store query — every request names the store environment it applies to.

So a tool you run across the portfolio holds one key per client. Name them for the client, scope them narrowly, and rotate them when the staff member who set them up leaves.

Reporting across clients

There is no cross-organization dashboard. Aggregate reporting means one API call per store, or an assistant connected per client.

For a recurring client report, the analytics endpoints (or the MCP tools) give you rating movement, review volume, top products and evidence coverage without screenshotting the dashboard.

Partner programme

If you refer merchants as well as managing them, there is a partner entitlement layer with commissions, client handoffs and agency checkout. The public partners page has the current rates and terms — treat it as the authority, and read it before quoting anything to a client.

Something missing or out of date? Email [email protected] — docs corrections go straight to the team that builds the feature.