Your integration portal, embedded in your app.
Customers configure their own destinations, view their own delivery logs, and replay their own failures, inside your dashboard. Drop in the React component, issue a session token, ship the feature.
Data Destinations
Configure where your events are delivered
Three steps to ship
From npm install to your customers managing their own destinations.
Install the React component
pnpm add @pushrail/embed-react in your dashboard app. Drop the <PushrailEmbed /> component wherever your integrations tab lives.
Issue a session token
From your backend, call Pushrail's session API with the signed-in customer's external ID. You get back a short-lived token scoped to that customer.
Pass the token to the component
The component renders the destinations UI scoped to the token's customer. Your customer configures destinations, you ship the integration feature.
What your customers can do
Every capability scoped to the signed-in customer. Tenant and sub-tenant isolation enforced at the API.
Configure their own destinations
Customers create webhooks, S3 buckets, BigQuery datasets, Kafka topics, and 14 more destination types from inside your dashboard.
Bring their own credentials
Customer-owned IAM roles, service accounts, and API keys. Pushrail stores them encrypted; the customer can rotate any time.
View their own delivery logs
Per-attempt detail, scoped to the signed-in customer. They see what failed without filing a ticket.
Replay their own failures
Customer picks a window or a single failed delivery and re-runs it. No engineering intervention needed.
See your brand, not ours
Theming reads from your design system. Colors, typography, and component shape all match your app.
Operate inside their tenant
Tenant + sub-tenant isolation enforced at the API and storage layer, customer never sees another customer's data.
Tenant and sub-tenant isolation
How a customer in your app sees their data, and only their data.
Pushrail's data model has two levels: a vendor tenant (you) and sub-tenants (your customers). Every destination, credential, delivery log entry, and audit row is tagged with the sub-tenant it belongs to.
When you issue a session token with the customer's external ID, the embedded component sees only that sub-tenant's data, even if the customer can guess another sub-tenant's identifier, the API rejects the request. There is no path through the UI to access another customer's data.
Customer-owned credentials never cross sub-tenant boundaries. A credential created by Customer A cannot be referenced from Customer B's destination, even by an operator on your side.
Session tokens and scoped credentials
Short-lived, customer-scoped, revocable.
Session tokens are JWTs signed by Pushrail with a short TTL (default 15 minutes). Your backend mints them on demand using your tenant API key; the embedded component refreshes them in the background as needed.
A token carries one piece of state: the sub-tenant it represents. No permission flags, no role data. The Pushrail API derives all authorization from the sub-tenant ID on every request, so there's no replay attack surface that lasts beyond the token TTL.
Revocation is immediate: invalidate the customer's session ID on your side and the next API call from the embedded component fails. No cache to wait out.