Airbyte Embedded
You set up airbyte embedded by linking your app to the Airbyte API. This lets your users run data syncs right inside your own app. Most teams start by sharing one broad admin key across their whole backend. If that broad key leaks, a bad actor can read every customer database. How airbyte embedded works in your app This setup uses a headless model driven by API calls. Your backend talks to the Airbyte control plane to make workspaces. Each customer gets a separate workspace to hold their sour
Embedded: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up airbyte embedded by linking your app to the Airbyte API. This lets your users run data syncs right inside your own app. Most teams start by sharing one broad admin key across their whole backend. If that broad key leaks, a bad actor can read every customer database.
How airbyte embedded works in your app
This setup uses a headless model driven by API calls. Your backend talks to the Airbyte control plane to make workspaces. Each customer gets a separate workspace to hold their sources and destinations. Your app renders a simple menu for the user to pick a source.
When a user logs into their source, your backend sends those keys over. Airbyte saves those keys and sets up a sync schedule for that user. Data then moves from the user source into your target database or warehouse. Your app checks the API to show sync status to the user.
How to scope workspaces and roles
Good isolation starts with strict workspace boundaries for every single customer. Never put two different customers inside the same workspace. You should map each customer account in your app to one workspace ID. This stops one customer from triggering a sync for another customer.
Next, you must lock down the destination database roles. Create a separate database user and schema for each customer workspace. Give that database user write permissions only to its own schema. Do not use a master database user for your customer sync jobs.
You also need to manage the API keys that your backend holds. Rotate these keys on a set schedule and store them in a vault. Limit which backend services can read these keys during a normal run.
What native setup solves and what it misses
Native workspace splits do a good job of isolating customer sync configs. They make sure Customer A cannot edit the sync rules of Customer B. Database roles also keep synced tables separate once the data lands.
Embedded: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, this setup only checks who can start a job or log in. It does not check what individual queries or requests do in flight. Once a sync or engineer logs into the target store, every row is open.
Engineers who debug failed syncs often log in with broad read roles. Those roles let them read raw tables full of customer data. Native database roles cannot mask emails, phone numbers, or card numbers on the fly. They also fail to log every single query tied to an engineer identity.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do you isolate tenant data during a sync?
Create a dedicated workspace and a dedicated destination schema for each tenant. Pair each schema with a unique database role that can only write there.
What happens when an engineer needs to debug a failed sync?
Engineers often query the target database or check API logs to find bad rows. Without field masking, those queries return live emails and card numbers in plain text.
Can native database roles mask sensitive fields in flight?
No, standard database roles only decide who can log in and read a table. To rewrite matched fields like national IDs in results, you need query inspection.
Teams that document these role rules and review logs each month catch config drift early. Clear ownership for each role keeps live systems simple to run and easy to audit across the whole team.