White-Label Execution

White-label execution means your customers use the workflow engine and integration builder from inside your product rather than from a ByteChef UI. This page describes what that covers today and what is still on the roadmap.

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.

What "white-label" actually covers

How customers interact with it

A typical embedded flow:

1. Customer signs in to your product as they always do.
2. Customer navigates to "Integrations" (or whatever you call it).
3. They see a list of integration templates you've defined for your product — pre-built workflows that solve common scenarios.
4. 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.
5. The workflow runs every time the trigger fires. Execution history is visible to them; nothing leaves your product.

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. See Tenant-Isolated Security for what that covers and what stays your responsibility.

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.