API Key Client Grouping for Resellers and Multi-Tenant SaaS

If you're an agency, contracting firm, or SaaS operator embedding a PDF generation API into a service used by multiple clients, the most painful monthly task is usually the same: figuring out which key belongs to which client, and how much each client used.

FUNBREW PDF solves this with client labels and tags on every API key. Generated PDFs, API logs, and usage data can all be filtered and aggregated per client, with CSV exports that include the client label so you can produce billing-allocation evidence in one click. See the full reseller patterns on the use cases page.

This guide walks through the operational pattern and best practices for reseller scenarios.

Why API key grouping matters

Common operational pain points

• Manual invoice allocation: spending the last day of every month aggregating "Acme used 10,000, Beta used 3,000" by hand
• Logs that can't be sliced: when something breaks for one client, you have to search the entire log stream
• Tribal knowledge: "wait, whose key is sk-xxxxx again?" — newcomers can't tell

What grouping fixes

Pain point	After grouping
Manual invoice allocation	Just look at the client_label column in the CSV
Filtering logs	One click per client
Tribal knowledge	Visible at a glance in the dashboard

When to use client_label vs tags

When in doubt, use the table below. The rule of thumb: the unit you want to split invoices by goes in client_label; everything else is a tag.

	client_label	tags
Count	Exactly one	Multiple allowed
Role	Primary axis for billing and aggregation	Sub-classification (environment, use case, etc.)
Example	Acme Inc	production, invoice-pdf
CSV export	Included as the client_label column (invoice evidence)	Not exported today — dashboard-only
Naming drift	Breaks filtering — use a strict convention	More forgiving

How to use it

Step 1: Tag each API key with client information

Dashboard → API Keys → "New key" or "Edit" on an existing key.

• Key name: an internal label (e.g. Acme Production)
• Client / Project: the client company or project name (e.g. Acme Inc)
• Tags: environment or purpose (e.g. production, invoice-pdf)

Tip: When you issue several keys for the same client (per environment, per use case), set the same client_label on all of them. The dashboard will then aggregate them into a single client view.

Step 2: Filter PDFs and logs by client

The PDF list and API log pages now have a "Client" filter.

If multiple keys share the same client_label (e.g. Acme's production key and staging key), the filter shows PDFs from both keys combined. The aggregation happens at the client level, not the key level.

Step 3: Export CSV for billing allocation

Running CSV export from the PDF list produces:

filename,original_name,source_type,file_size,download_count,...,api_key,client_label
abc123.pdf,"acme-invoice-2026-04.pdf",html,254078,1,...,Acme Production,Acme Inc
def456.pdf,"beta-contract.pdf",html,128400,2,...,Beta Production,Beta Corp

Pivot on client_label and you instantly have per-client generation counts, file sizes, and download counts. Monthly billing becomes nearly self-serve.

Best practices by reseller scenario

Scenario 1: Agency model (separate billing per client)

client_label: "Acme Inc"       tags: ["production"]
client_label: "Acme Inc"       tags: ["staging"]
client_label: "Beta Corp"      tags: ["production"]
client_label: "Gamma Studio"   tags: ["production", "trial"]

• Group monthly CSV by client_label → use as the basis for each client's invoice
• Mark trials with a trial tag and update to production on conversion

Scenario 2: Multi-tenant SaaS

client_label: "tenant_001"  tags: ["plan:pro", "production"]
client_label: "tenant_002"  tags: ["plan:enterprise", "production"]

• Use the tenant ID as client_label so it joins cleanly against your own DB
• Keep plan info in tags to detect overage candidates

Scenario 3: Project-based contracting

client_label: "Project Alpha"  tags: ["delivered", "support-2026"]
client_label: "Project Beta"   tags: ["development"]

• Tag delivered projects with delivered, and use support-yyyy for active warranty windows
• Pull only the relevant logs when a support ticket lands

Design considerations

Grouping is a management label

client_label and tags are metadata for filtering and aggregation in the dashboard. They do not change API behavior (rate limiting, billing, scopes). To enforce per-client rate limits, keep using separate keys; grouping just makes them easier to manage.

Keep keys safe

Rather than handing API keys directly to clients, the recommended reseller pattern is to proxy client requests through your own backend, which holds the FUNBREW PDF key. Issue separate keys per client, label them, and a leak only impacts one client — rotation stays surgical.

Decide on a naming convention up front

When several people manage keys, label drift (Acme Inc / acme inc / Acme Inc.) breaks filtering. Agree on a convention (e.g. legal name, single space, no honorifics) before you start tagging.

Summary

For anyone reselling a PDF generation API, key grouping makes three things dramatically easier: invoice allocation, support response, and operational handoffs.

• client_label aggregates per client
• tags slice further by environment or purpose
• CSV exports automate billing allocation

Already issued keys? Just edit them in the dashboard to add client_label and tags — past PDFs and logs are filterable retroactively.

Read the full documentation or head to the API keys dashboard to start grouping. To experiment with the API itself first, try the playground. For a broader take on invoice automation, see the invoice API guide.