Ship native integrations inside your SaaS

Your users authenticate with the services they already use - Gmail, Slack, HubSpot, AWS S3 and 276+ more - and your product triggers workflows on their behalf. No integration team, no per-vendor OAuth code, no credential storage of your own.

Become a design partner
  • 276+ connectors
  • Apache 2.0 core
  • Self-host or cloud
  • Per-tenant isolation

Your customers keep asking for integrations

Each one looks like a week and turns into a quarter. OAuth consent and token refresh. Pagination and rate limits that differ per vendor. Retries, replay, and the question of what happens when a third-party API is down for six hours. Per-tenant credential storage, and the security review that follows it. Then the second integration arrives and none of it generalizes.

And it does not end at shipping. Someone has to see which customers connected what, whose credentials went stale overnight, and why one tenant’s sync failed at 3am - per environment, per user, forever.

Everything your product needs to offer integrations

Available today, documented today. Build an integration once against any of 276+ connectors, deploy it per environment, and let every one of your customers connect their own account to it.

Embed

Connect dialog

A hosted dialog you open from your own app. It walks your user through OAuth consent or API-key entry, enables the integration’s workflows, and collects any workflow inputs, then stores the credentials against their connected-user record. You never handle or refresh a token.

Read the docs
Embedded workflow builder

Render the full visual workflow editor inside your product, restricted to the component set you choose. Your customers compose their own automations without leaving your UI.

Read the docs
React SDK and signed JWTs

Your backend mints a short-lived JWT with your own signing key and the frontend hands it to the SDK. You own identity, and we never hold your user table.

Read the docs
Sample app

A runnable Next.js and Fastify reference implementation of the entire flow, end to end.

Read the docs

Build

Integrations

Build an integration against any connector, with its own workflows, versioned as a draft or published. Edit it in the visual editor, or import it from JSON or YAML.

Read the docs
Permission expressions

Gate which integrations and workflows each connected user can see, with an expression evaluated per request. Premium connectors for paying tiers, GDPR-cleared ones for EU customers, betas for flagged accounts. It fails closed.

Read the docs
App events

Define an event in your product, such as a signup or a placed order, and let each customer attach workflows to it. One event can fan out to many workflows.

Read the docs
Field mapping

Map fields between your product schema and each third-party model, without hand-writing transformation code for every integration.

COMING SOON
Read the docs
Component Kit

A backend Java SDK, with a Spring AI integration, that turns the component actions a connected user can reach into tools your own LLM application calls.

Read the docs

Operate

Instance configurations

Deploy a published integration version into Development, Staging or Production, each with its own connections and workflow settings. Toggle one on or off without deleting it.

Read the docs
Connected users

Every user of your product who has connected something, in one searchable table: external id, credential status, and which integrations they use. Click through for per-user connection detail.

Read the docs
Connections

Per-user, per-environment credential storage with an active or not active status on every one. Development credentials stay separate from production by construction.

Read the docs
Workflow executions

Every run, step by step, filterable by status, date range, integration, configuration, workflow or connected user. This is what you open when one customer’s sync failed at 3am.

Read the docs

Administer

Signing keys

RSA-2048 keys for minting end-user JWTs. The private key is shown exactly once.

Read the docs
API keys

Bearer tokens for server-to-server calls, scoped per environment.

Read the docs

The failure mode you cannot afford

In an embedded iPaaS the worst thing that can happen is cross-tenant leakage - one customer’s workflow seeing another’s data, or running with their credentials. ByteChef is built so the default is safe, and you would have to actively misconfigure something to leak.

Identity

Every API call, webhook and scheduled fire carries a tenant id derived from the authenticated principal, resolved before anything touches data.

Routing

Schema per tenant. Every database connection is pinned to that tenant’s own schema for the duration of the request, and file storage is written under a per-tenant prefix.

Crypto

Credentials are encrypted with AES-GCM before they reach the database. Plaintext exists only in memory at execution time, and reads never return a secret.

Observability

Logs and traces carry the tenant tag, so one tenant’s activity is never read as another’s.

What that lets you offer your customers

A native integrations page in your product

Your customer picks a service, authorizes their own account in a dialog that lives inside your UI, and it works. No support ticket, no professional-services engagement. You get a table of who connected what and whether their credentials are still good.

Built from: Connect dialog, Integrations, Connections, Connected users

Your product events, wired into their stack

A signup in your app creates the contact in their CRM and sends a welcome email. An order creates an invoice in their accounting system and posts to their Slack. You define the event once; each customer’s workflow runs against their own connections.

Built from: App events, Instance configurations

Integrations as tiers, and as AI tools

Gate the premium connectors to paying plans with an expression instead of a fork in your code. Then expose what each user has connected as tools your own agent can call, acting with their credentials.

Built from: Permission expressions, Component Kit

Build AI products on top of ByteChef

Building an AI application rather than an integrations page? Component Kit lets your product use the connections your customers have already configured, so your agent can take actions across their business systems without you building every integration yourself, and without holding any of their credentials.

It is a backend Java SDK with a Spring AI integration: fetch the component actions a connected user can reach, hand them to your model as tools, and each call runs with that user’s own credentials. What it exposes is component actions rather than whole workflows - to give an agent a whole workflow, publish it through an MCP server or trigger it with an app event.

Explore Component Kit

What’s open source, and what isn’t

Apache 2.0 - open source

The workflow and agent engine

Every connector in the catalog

The SDK for building your own connectors

Self-hosted deployment of the automation platform

ByteChef Enterprise - commercial

The whole embedded layer: embedded UI and APIs

Connect dialog, embedded workflow builder, React SDK

Connected users, per-user connections, app events

Permission expressions, Component Kit

Both halves live in the same public repository. You can read the embedded layer’s source before you talk to us, run it on a free evaluation licence, and take it to production once you are convinced. What you cannot do is run the embedded layer in production without a licence - Embedded requires an Enterprise deployment, and the open-source build does not expose it. That is the commercial line, and it is the only one.

We’re taking on 5 design partners this quarter

We build your first three integrations with you. You get a shared Slack channel, direct roadmap influence, and founder-level support. In exchange we ask for honest feedback and, if it goes well, a case study.

Book 15 minutes

Frequently asked questions

Focus on what matters,automate the rest.

ByteChef logo
Copyright © 2026 ByteChefAll rights reserved
Subscribe to our newsletter