Want to shape ByteChef with us?
Become a design partner and get hands-on guidance from our team as we tackle your automation challenges together, while helping shape ByteChef around your business needs.
Let your users connect the tools they already trust, like Gmail, Slack, HubSpot or AWS S3, from a library of 283+ integrations. Every account they connect becomes a workflow your product can run and a tool your AI agent can call, under their own credentials. You won't need an integration team, custom OAuth code for every vendor, or your own place to store their credentials.
Become a design partner and get hands-on guidance from our team as we tackle your automation challenges together, while helping shape ByteChef around your business needs.
Each integration build looks like a week of engineering work, but in practice turns into a quarter once you account for everything it actually requires.
OAuth consent flows and token refresh, different for every vendor.
Pagination and rate limits that differ per vendor.
Retries, replay and what happens when a third-party API is down for six hours.
Per-tenant credential storage and the security review that follows it.
The build cycle above doesn’t end at shipping, because someone still has to track which customers connected what, whose credentials went stale overnight and why one tenant’s sync failed at 3am, per environment, per user, forever.
With every one of ByteChef’s 283+ connectors documented and ready today, you build the integration once and deploy it across as many environments as you need, while each customer connects their own account to it.
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.
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.
An embeddable end-user portal where your customers browse the workflow templates you publish, activate one through a guided wizard, then manage their own automations and connections without leaving your product.
Ask and Build modes in the integration workflow editor, so you author an integration’s workflows by describing them. The same Copilot API generates a starter workflow for a connected user from a natural-language prompt.
A runnable Next.js and Fastify reference implementation of the entire flow, end to end.
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.
Every account your customer connects is a tool your model can call. Ask Component Kit for the actions a connected user can reach and it returns them as tool definitions, with the names, descriptions and JSON-schema parameters your model already expects. Post back the one the model picks and ByteChef runs it with that user’s own credentials, resolved server-side. Your application never holds a token, and you never write per-integration glue for the model to call.
It is a REST API with adapters on top: Spring AI for Java, the Vercel AI SDK for TypeScript, and a sample app with a working tool-calling chat you can run today. What it exposes is actions. To hand an agent a whole workflow instead, publish it to an MCP server, which is coming soon, or trigger it with an app event.
The harder half of an agent is not calling the tool, it is knowing what a model may reach and proving what it did. Permission expressions are evaluated per user on every request and fail closed, so the answer never depends on prompt discipline. Every invocation lands in the execution log with its tenant tag. And the engine underneath is Apache 2.0: the agent loop your customers’ prompts and credentials pass through is code you can read, fork and run in your own VPC, rather than a black box behind someone else’s API key.
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.
The same four layers are what bound an agent. A model calling a tool reaches only what that connected user authorized, under their credentials, inside their schema, and every invocation lands in the execution log with their tenant tag on it. A prompt cannot talk its way past any of that, because none of it is enforced in the prompt.
Every API call, webhook and scheduled fire carries a tenant id derived from the authenticated principal, resolved before anything touches data.
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.
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.
Logs and traces carry the tenant tag, so one tenant’s activity is never read as another’s.
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.
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.
Your agent books the meeting, files the ticket and updates the CRM record in the customer’s own accounts, because every action they connected is already a tool your model can call. Which tools each plan reaches is an expression, not a fork in your code, and it fails closed.
ByteChef’s workflow and agent engine, plus every connector in the catalog, is open source under Apache 2.0, which means the code is public: anyone can read it, run it and self-host it for free. Embedded, the commercial layer this page is about, sits on top of that core. Its source is in the same repository, but running it in production needs a paid ByteChef Embedded plan.
| Open source (Apache 2.0) | Commercial (ByteChef Embedded) |
|---|---|
| The workflow and agent engine | The whole embedded layer: embedded UI and APIs |
| Every connector in the catalog | Connect dialog, embedded workflow builder, React SDK |
| The SDK for building your own connectors | Connected users, per-user connections, app events |
| Self-hosted deployment of the automation platform | 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 a paid plan, and the open-source build does not expose it. That is the commercial line, and it is the only one.
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.
Curious what's coming or waiting for a feature to ship? Subscribe to be the first to know when it launches, plus get release notes, new feature announcements and subscriber-only discounts.
By subscribing, you agree to receive emails from ByteChef and to our Privacy Policy. You can unsubscribe at any time.
By subscribing, you agree to receive emails from ByteChef and to our Privacy Policy. You can unsubscribe at any time.