White-Label Execution

Expose ByteChef's workflow engine inside your SaaS. Your customers build integrations; you don't build an integration team - and no tenant can reach another's workflows, credentials or data.

White-label execution means your customers use the workflow engine and integration builder from inside your product rather than from a ByteChef UI. Each of them is a tenant, and the failure that matters is one tenant seeing another's data. This page covers both halves: what your customers see, and what keeps them apart.

The mental model

       Your SaaS product
       ┌────────────────────────────────┐
       │  Your UI / Your branding       │
       │  ┌──────────────────────────┐  │
       │  │  ByteChef-rendered       │  │
       │  │  workflow builder        │  │  ◄── embedded via iframe / SDK
       │  │  (white-labeled)         │  │
       │  └──────────────────────────┘  │
       │  ┌──────────────────────────┐  │
       │  │  Your business logic     │  │
       │  └──────────────────────────┘  │
       └────────────────────────────────┘
                      │
                      ▼
       ┌────────────────────────────────┐
       │  ByteChef Enterprise           │
       │  ┌──────────────┐  ┌────────┐  │
       │  │ Tenant A     │  │ Tenant │  │
       │  │ workspace    │  │   B    │  │  ◄── per-customer isolation
       │  └──────────────┘  └────────┘  │
       └────────────────────────────────┘

Your customer never sees "ByteChef." They see your product offering integrations.

How customers interact with it

Your product chrome wraps the builder, which renders in an iframe you position. A typical embedded flow:

Customer signs in to your product as they always do.
Customer navigates to "Integrations" (or whatever you call it).
They see a list of integration templates you've defined for your product - pre-built workflows that solve common scenarios.
They configure a connection to their external system (Salesforce, etc.) by completing the standard auth flow. The credentials live in encrypted credential storage, scoped to their tenant.
The workflow runs every time the trigger fires. Execution history is visible to them; nothing leaves your product.

The component catalog they browse is the built-in one, restricted to the set you pass as includeComponents.

Two integration models

Pre-built templates

You define a library of integrations as templates. Customers don't build from scratch - they pick a template, configure their connections and parameters, and turn it on. Best for product teams that want curated, supported integrations.

Builder access

You give customers the visual workflow builder and let them build whatever they want. Best for technical customers and developer-tool products.

You can mix - offer templates as the on-ramp, expose the builder for power users.

What "execution" means here

When a customer's workflow runs:

It runs on your ByteChef deployment, isolated to that customer.
It uses their connections (their Salesforce key, their Slack token).
It executes against their business logic (your custom components plus the built-in ones).
It generates execution history they can see in your product UI.

One customer's run cannot read another's data, connections, or history. The rest of this page is what that covers.

Tenant-isolated security

This is what you can tell your own security reviewers - what the platform guarantees, what you have to do to keep it true, and where the boundary stops.

What you get without configuring anything

A customer's data is reachable only from that customer's tenant. Every request - an API call, a webhook, a scheduled run, an MCP call - resolves which tenant it belongs to before it touches any data, and stays pinned to that tenant for its whole life. There is no "list everything" call to get wrong: the APIs list what is in one tenant, not what exists.

A credential belongs to the customer who authorized it. Connections are encrypted before they reach the database and are never returned by a read - the API obfuscates them on the way out. A connection your customer authorizes is bound to their own record, so it is never offered to another customer, and the plaintext exists only in memory while their own workflow is running.

A customer's own end users stay separated too. Inside one tenant, each connected user's connections are reachable only through that user's own integration instances.

Knowledge bases don't bleed. One tenant's indexed documents are never searched by another's.

Logs are attributable. Every log line carries the tenant it was written for, so you can hand one customer their own audit trail without filtering by guesswork.

You do not switch any of this on. It is how the platform runs, including on a single-tenant deployment - there, everything simply resolves to one tenant.

Where the boundary stops

Four things are worth knowing before you describe isolation to a customer, because none of them is what a reader would assume:

The encryption key is per deployment, not per tenant. Separation of credentials comes from the tenant boundary, not from separate key material. A single key protects everything in the deployment against a stolen database; it does not make one tenant's ciphertext unreadable to another tenant's code path. If a customer needs their secrets in their own vault, external secret managers are (coming soon).

Queues are shared. Runs for different tenants pass through the same message broker, each message carrying the tenant it belongs to. The data each run reads and writes is isolated; the pipe is not.

Metrics and traces are not tagged by tenant. Logs are. If you need per-customer dashboards or per-customer alerting, derive them from the logs or add the tag in your own collector.

There is no per-tenant rate limiting. One customer's traffic can affect another's latency. That limit belongs at your ingress - see below.

What stays yours to do

Issue a distinct token per tenant. Never let a "master" token serve runtime traffic; a token is what decides which tenant a request lands in.
Rate-limit per tenant at your own ingress, so one noisy customer cannot degrade the rest.
Supply the encryption key from your secret manager, not a checked-in config file (BYTECHEF_ENCRYPTION_PROVIDER=PROPERTY).
Back the key up separately from the database. A restored database without its key is unreadable - every stored credential is lost.

Custom components for your product's logic

The integration catalog you give customers can include custom components you write - for example, a "Your Product" component with actions like "create a record" or "look up a customer." That lets you bundle your own product as a first-class integration point in the workflows your customers build.

What you don't have to do

Build a visual workflow builder.
Build connectors.
Build an execution engine.
Build credential storage.
Build a webhook ingress.
Build a scheduler.
Build observability and execution history.

All of those come with the platform. You build the product wrapper - branding, billing, customer onboarding, your business logic.

What your customers get

Hundreds of integrations without you having to build them.
A visual workflow builder they can use without writing code.
Their own connections - they bring their own credentials; you don't see them.
Their data, isolated - your other customers can't see their workflows or data.

What it means for you

The built-in components are maintained in ByteChef, so adding a provider is a version bump rather than new integration code.
Embedded runs in the ByteChef deployment you already operate - there is no separate service to stand up.
You decide what your customers are charged; ByteChef bills you for the deployment.