Per-tenant reporting: giving partners visibility without breaking isolation
Per-tenant reporting is the practice of scoping every dashboard, export, and webhook so a brand, retailer, or seller on a shared returns network sees only its own data, never a neighbor's, while the operating partner still gets a rolled-up view across the whole book. At areturnz, this is built into the reporting layer itself: each tenant's grades, disposition outcomes, and evidence bundles are walled off by design, and the 48 hour median cycle time and 99.6% AI-vs-operator match accuracy we publish network-wide can also be sliced down to a single tenant's own numbers on request.
Why per-tenant reporting is harder than it sounds
Most returns software was built for one company looking at its own data. A white-label partner running returns for a dozen brands under one roof has a different problem: the underlying facility, the receiving line, and the grading model are shared, but the reporting has to behave as if each brand has its own private system. Get this wrong and a brand manager can accidentally see a competitor's SKU volume, restock rate, or defect trend, which is the kind of leak that ends a partner contract fast.
The fix is not a second database per tenant. It is a permissions and query model that treats tenant_id as a first-class filter everywhere data can be touched: dashboard, API, webhook payloads, CSV exports, even support tickets. We cover the messaging side of this in multi-tenant webhook isolation, and per-tenant reporting is the read-side twin of that same problem.
What a tenant should actually be able to see
A brand on the network needs enough visibility to trust the numbers and act on them, but not so much that reporting becomes a second job. In practice that means:
- Inbound volume and cycle time for their own SKUs only, benchmarked against the network median (currently about 48 hours from inbound scan to disposition)
- Grade distribution across A, B, C, and R for their returns, with confidence scores attached to each grade
- Disposition outcomes: restock, liquidate, donate, destroy, broken out by reason and by operator override rate
- Evidence bundle access for any specific return, pulled by order ID or tracking number
- Exception queues: anything routed for manual review, with the AI's original grade and confidence shown alongside the operator's final call
What they should not see: other tenants' SKUs, other tenants' aggregate rates, or facility-level operational detail that has nothing to do with their own returns. The line is drawn at "your data plus network benchmarks," not "everything the operator can see."
Dashboard, API, and webhook: three surfaces, one scope rule
Per-tenant reporting has to hold up across every surface a partner or brand might use, not just the dashboard someone logs into once a week.
| Surface | What it exposes | Isolation control |
|---|---|---|
| Dashboard | Grades, dispositions, cycle time, evidence bundles | Tenant-scoped login, role-based views for brand vs. corporate vs. read-only auditor |
| Signed-JSON API | Same data, queryable and exportable programmatically | Tenant-scoped API keys, every request filtered server-side by tenant_id |
| Webhooks | Real-time disposition and grading events | Separate signing secret and endpoint per tenant, no shared event bus payloads |
| Scheduled exports | CSV or JSON dumps for finance and ops reconciliation | Generated per tenant on a per-tenant schedule, never a filtered slice of a combined file |
The reason the exports row matters as much as the API row: a lot of leak incidents in shared platforms come from someone filtering a combined CSV in a spreadsheet rather than generating a properly scoped file at the source. Reporting isolation has to happen at generation time, not at the point someone opens the file.
Rolling up without flattening: what the operating partner sees
The operator running the network still needs a combined view: total volume across 180K+ returns processed, network-wide match accuracy, facility throughput at NJ-01 in East Hanover, capacity planning across all tenants. That view has to exist without becoming a backdoor into any single tenant's detail. The pattern that works is aggregation at query time, not storage of a pre-flattened table that any admin account can browse row by row. If an operator needs to drill into one tenant's numbers for a support case or an SLA review, that access should be logged the same way grading overrides are logged, so there's an audit trail of who looked at what and when.
This matters for the same reason evidence chain of custody matters on the physical side: a partner's willingness to resell the network depends on being able to tell their own brand clients, truthfully, that their data is not visible to competitors also running returns through the same facility.
Reporting cadence and SLA tie-in
Per-tenant reporting is only useful if it lines up with the commitments a partner has already made to their brand. If an SLA promises a 48 hour disposition window, the tenant's dashboard needs to show actual cycle time against that number in real time, not a monthly PDF that arrives three weeks late. We go deeper on how those commitments get structured in SLA design for white-label returns partners, but the short version is that reporting and SLA design have to be built together. A dashboard that shows pretty charts but doesn't map to the contract terms isn't reporting, it's decoration.
Most partners settle into a rhythm of real-time dashboard access plus a weekly digest and a monthly reconciliation export. The digest catches drift early (a tenant's C-grade rate creeping up, say), and the monthly export is what finance uses to true up chargebacks, liquidation proceeds, and restock value against their own books.
Where evidence fits into tenant-level reporting
Every return in the network still gets photographed at receiving, still gets an A/B/C/R grade with a confidence score, and still ships with an evidence bundle. Per-tenant reporting just means that bundle, and the dashboard entry pointing to it, is only retrievable by the tenant that owns the return and by the operator account with logged access. A brand disputing a chargeback pulls their own evidence through their own scoped view, using the same kind of package shown on our evidence sample page, without any risk of pulling or being shown another tenant's parcel photos by accident.
Getting the reporting model right before onboarding, not after
The mistake we see partners make is treating reporting scope as a configuration step to handle after the first few brands are live. It's much cheaper to design tenant boundaries into the schema and the dashboard permissions from day one than to retrofit isolation once three brands already have logins and some of them have already seen more than they should have. If you're evaluating whether to build this yourself or run it on an existing network, our white-label returns platform playbook covers the broader partner setup, and per-tenant reporting is one piece of that foundation, alongside webhook isolation and SLA design.
For partners already live, a reasonable audit is worth running now: pull every export a tenant received in the last quarter and confirm none of them contain another tenant's identifiers, SKUs, or evidence bundle links. It's a small exercise that either confirms your isolation model works or catches a gap before a brand client finds it first.
Frequently asked questions
What's the difference between per-tenant reporting and role-based access control?
Role-based access control governs what a person can do within an account (view only, edit dispositions, export data). Per-tenant reporting governs which account's data exists in the first place. You need both: RBAC decides what a logged-in user can touch, and tenant scoping decides which tenant's rows are even in scope for that user regardless of role.
Can a tenant see network-wide benchmarks like the 48 hour cycle time or 99.6% match accuracy?
Yes. Aggregate, anonymized network benchmarks are useful context and don't expose any other tenant's specific data. A brand can see how their own cycle time and grading accuracy compare to the network median without seeing any other brand's raw numbers.
Does per-tenant reporting slow down webhook delivery or API response times?
No. Tenant scoping is a filter applied at the query and signing layer, not an extra processing step that adds latency. Properly indexed by tenant_id, scoped queries run at the same speed as unscoped ones.
Who audits access when an operator needs to look at a specific tenant's data for support?
That access gets logged the same way grading overrides are logged: who accessed it, when, and for what reason. It's not blocked outright, since support and SLA reviews sometimes require it, but it's never silent.
How does this fit with data residency or privacy requirements like GDPR?
Tenant-scoped reporting is a natural fit for data minimization principles: each tenant's data processing agreement covers only what that tenant can actually access, and cross-tenant leakage risk is architecturally reduced rather than just policy-enforced. Check our data processing agreement for specifics on how this is documented contractually.
If you're running returns for multiple brands or building a resold returns program and need reporting that partners can actually trust, get in touch and we'll walk through how tenant isolation works on the areturnz network.
