Tenant-scoped event delivery for multi-tenant SaaS
Your product has tenants. Their events should go to their destinations, on their credentials, with audit boundaries that survive a compliance review. Build it on a platform that enforces isolation, not in spreadsheets.
The problem
Multi-tenant SaaS sounds simple until events come into play. Every customer has different destinations. Every destination needs different credentials. Every audit log entry needs to be attributable to one tenant, not the system overall. Mixing any of those across tenant boundaries is a P0 compliance incident waiting to happen.
The DIY path is treacherous. A bug in a routing rule sends Customer A's data to Customer B. A credential gets reused across tenants. A delivery log query scoped wrong shows a customer another customer's failures. Each of these is a single-line code mistake away.
The hard part isn't 'support multi-tenancy.' It's enforcing tenant scoping in every code path that touches a destination, a credential, a delivery, or an audit row, and proving you did it.
How Pushrail solves it
Pushrail's data model is two-level: a vendor tenant (you) and sub-tenants (your customers). Every destination, credential, delivery log entry, routing rule, and audit row is tagged with its sub-tenant. API endpoints derive authorization from the request's sub-tenant scope on every call.
There is no path through the API or the embedded portal to access another sub-tenant's data. The isolation is enforced at the database row level via tenant-scoped queries and validated at the API contract layer.
When a customer's compliance team asks 'how do you isolate our data?', you point at the architecture instead of a runbook.
What you ship to your customers
- Per-sub-tenant destinations: each customer configures their own webhooks, warehouses, queues.
- Per-sub-tenant credentials encrypted at rest, never reusable across tenants.
- Per-sub-tenant delivery logs and audit trail, scoped queries, no cross-tenant leakage.
- Per-sub-tenant routing rules: Customer A's events never accidentally route to Customer B's destination.
- Pushrail-issued session tokens that bind to one sub-tenant; the embedded UI cannot see beyond that scope.
What this replaces
- Bespoke `tenantId IS NOT NULL` scoping logic scattered across every query in your codebase.
- Spreadsheet-tracked credentials that 'should be' scoped per customer.
- An audit log that requires a SQL join to even answer 'what did Customer A see?'
- Annual penetration-testing findings about tenant isolation gaps.
Concrete walkthrough
- 1. When your customer signs up, create a sub-tenant in Pushrail via the admin API.
- 2. Send events with the `customerExternalId` field set to that sub-tenant's identifier, Pushrail routes accordingly.
- 3. The customer configures destinations through the embedded portal (scoped to their session token) or you configure on their behalf via the admin API.
- 4. Every credential, destination, delivery, and audit row is auto-scoped, no manual `WHERE tenant_id =` checks in your code.
- 5. Compliance reviewers see the scoping enforced architecturally; they don't ask for a code audit.
Destinations this uses
HMAC-signed JSON POSTs with retries, replay, and a per-attempt audit trail.
Deliver events as NDJSON files into a customer-owned S3 bucket, batched, partitioned, and idempotent.
Stream events directly into a customer's BigQuery dataset, table per event type or single wide table.
Native Kafka producer with SASL/TLS, deliver events into a customer's topic with configurable partitioning.
Related use cases
Let enterprise customers point your events at their own infrastructure, close the ACV-driving deals without bespoke engineering.
Drop an embedded portal into your app where customers configure their own destinations, without building the portal yourself.
Close 'where does our data go?' procurement asks with a productized export feature instead of a custom commitment.
Frequently asked questions
How does Pushrail model tenants?
Two levels: a vendor tenant (you) and sub-tenants (your customers). Every destination, credential, delivery log entry, routing rule, and audit row is tagged with its sub-tenant, and API endpoints derive authorization from the request's sub-tenant scope on every call.
Can one customer ever see or trigger another customer's deliveries?
No. There is no path through the API or the embedded portal to access another sub-tenant's data. Isolation is enforced at the database row level via tenant-scoped queries and validated at the API contract layer.
Do I have to write tenant-scoping logic in my own code?
No. Once you send events with the customerExternalId set, every credential, destination, delivery, and audit row is auto-scoped, there are no manual WHERE tenant_id = checks scattered across your queries.
How does this hold up in a compliance review?
Because scoping is enforced architecturally rather than in a runbook, you can point a customer's compliance team at the isolation model, row-level scoping plus contract-layer validation and sub-tenant-bound session tokens, instead of producing a code audit.
Tenant-scoped event delivery for multi-tenant SaaS
Sandbox is open. No credit card.