EMBEDDED TWO-WAY SYNC
Embedded two-way sync for SaaS and AI products.
Per-customer Salesforce, HubSpot and NetSuite sync into your own Postgres, Snowflake or warehouse, managed from your code through the Management API on Pro and up.
To embed two-way sync in your product, run one sync per customer: connect that customer's CRM or ERP with their own credentials and sync the mapped objects into a database your application already reads, such as Postgres or Snowflake. Your code reads and writes plain tables, and Stacksync carries each change back to the customer's system, with API rate limits and failed writes handled per sync.
Embedded two-way sync at a glance
What your team builds on, and where each piece is documented.
| What it is | Two-way sync between each of your customers' business systems and a database your product owns, run as one sync per customer. |
|---|---|
| Customer systems | CRMs such as Salesforce and HubSpot, ERPs such as NetSuite, and warehouses such as Snowflake, from the Stacksync connector catalog. |
| Where the data lands | Your Postgres or another supported database or warehouse, in the schema or database you choose for each customer. |
| Provisioning | Configuration as code for syncs and the Management API from Pro up; workflow configuration as YAML or JSON on every plan. |
| Writes that need an answer now | The API proxy, on every plan, with daily call limits by plan and unlimited calls on Enterprise. |
| API limits | Smart API rate limits cap the requests each sync sends to a customer's app. |
| Failed writes | The Issues dashboard: retry, revert or ignore, with bulk actions and API-based resolution. |
| White-label | Enterprise plan. The OEM partner track covers reselling under your brand. |
| Pricing | Based on active syncs and records in sync; embedded deployments are quoted on Enterprise. |
Plan limits and gates are on the pricing page. Issue handling is described in issue management, and rate limits in smart API rate limits.
How embedded sync works: one sync per customer
An embedded integration is the same two-way sync your own team would run, repeated for every customer who connects a system. The work moves from writing connectors to managing a template and a tenant boundary.
Set the tenant boundary
Decide where each customer's records land: a schema per customer in a shared Postgres, or a database per customer. Pick by your isolation and operations needs; each sync writes only to the destination you configure for it.
Write one sync template
Map the objects and fields your product needs, set the write direction for each table, and, from Pro up, keep the sync configuration as code next to your own. Fields you leave unmapped are not synced.
Create a sync per customer
When a customer turns on the integration, their own admin authorizes the connection with their account credentials, and you create their sync from the template. Stacksync holds those credentials, so your application does not store them. The Management API and configuration as code for syncs, available from Pro up, let your backend create and update each sync from the template; confirm during scoping how each customer authorizes their connection for every system you offer.
Build on plain tables
Your application and agents query the synced tables and write changes to them. Two-way sync carries permitted edits back to the customer's CRM or ERP, and sync event triggers can start a workflow when a record changes.
Operate each customer's sync
Watch sync statistics per customer, resolve failed writes in the Issues dashboard, and route alerts to email on every plan or to Slack, webhooks, PagerDuty and other tools on Enterprise.
Running on Supabase? The Supabase integration covers per-tenant credentials on top of row-level security. Building agents that act on synced data? See AI agents.
Writes from your product and your AI agents
Your product writes to customer systems in two ways. Pick the path by whether the caller has to know the outcome before it moves on.
| Path | Use it for | What your code sees |
|---|---|---|
| Two-way sync | Updates to existing records, bulk changes, and anything your product can apply by editing a row. | A row change in your database. If the customer's system rejects it, the record appears in the Issues dashboard. |
| API proxy | Creates and deletes where the caller needs the result in the same request, such as an agent that must know whether a new record was accepted. | The customer app's response, including validation errors, returned to your code right away. 50k calls a day on Starter, 150k on Pro and Managed Pro, unlimited on Enterprise. |
For AI products we recommend a split: agents send creates and deletes through the API proxy, so an error comes back while the agent can still act on it, and they make updates by editing synced rows. Reads stay on the local copy in both cases.
When a customer's CRM rejects a write
Every customer runs their own validation rules, required fields and permissions, and you control none of them. Some write-backs will fail, and how many depends on the customer. Each failure lands in the Issues dashboard with the error the customer's system returned. You can retry after the cause is fixed, revert to the other system's value, or ignore the issue if your product can live with the difference. Bulk actions and API-based resolution handle issues at volume.
Staying inside each customer's API limits
Calling a customer's Salesforce for every agent read spends their daily API allowance fast. With sync, reads hit your database and the sync spends API calls on changes. Smart API rate limits cap the requests each sync sends to an app per second or per minute, so each customer's sync stays inside the budget you set for their org.
Build, unified API, embedded iPaaS or embedded two-way sync
Teams that need customer CRM and ERP data in their product usually weigh the same five options. They differ in where the data lives and in how much integration code stays with your engineers.
| Approach | Examples | What you get | What to check |
|---|---|---|---|
| Build in-house | Your own connectors | Full control over every connector and data model. | Who owns authorization, token refresh, pagination, rate limits, schema changes, retries and on-call for every system, for every customer. |
| Unified API | Merge and similar | One request format across many apps in a category. | Whether the custom objects and fields your customers use fit the common model, and who stores and reconciles any copy you keep. |
| Integration infrastructure | Nango and similar | Managed authorization, connections and API access across many apps. | How much of the sync logic, conflict handling and failed-write recovery your engineers still write and run. |
| Embedded iPaaS | Paragon, Workato Embedded | Customer-facing integration setup and workflow building blocks. | Whether record-level two-way sync is native or assembled from workflows, and how pricing scales per end customer. |
| Embedded two-way sync | Stacksync | Per-customer two-way sync into your own database, with rate limits and issue handling per sync. | Plan gates: the Management API from Pro, white-label on Enterprise. See pricing. |
Buyers who had built connectors themselves described integration work that took up most of a small engineering team. The deciding question is usually whether your product needs a live copy of customer records or only occasional calls. If it needs the copy, a sync layer removes the most code.
Vendor scopes change often, so check each one's current documentation. Related reading: Stacksync as a Workato alternative and white label vs. Powered by Fivetran.
Pricing for embedded use
Stacksync is priced on active syncs and records in sync. Plans include 1 active sync on Starter, 3 on Pro and unlimited on Enterprise.
Embedding usually means one sync per customer, so embedded deployments run on Enterprise. That plan adds unlimited syncs, the white-label platform, unlimited API proxy calls and volume-based discounts, and it is quoted by sales. Compare plans or talk through your tenant count.
Security and deployment
Your customers will ask how their CRM data is handled. Stacksync's compliance program covers SOC 2 Type II and ISO 27001, and the plan comparison shows which plan includes each. The security page and compliance center cover the details. You choose the processing region for your syncs, with custom regions on Enterprise.
For customers whose systems sit behind a firewall, SSH tunneling is available on every plan. Enterprise adds on-premise deployment, reverse SSH tunnels, VPC peering, VPN gateways and private networking.
Systems outside the catalog
Customers bring niche CRMs and ERPs. Build a custom connector with the Stacksync CDK on any plan, or have professional services build it with you. Browse existing CRM and ERP connectors first.
Embedding vs. the OEM program
This page is for product teams running customer syncs inside their own application. If you want to resell Stacksync or offer it under your brand as a commercial line, the OEM track on the partners page covers that program.
FAQ
Embedded sync questions
What is the best way to embed bi-directional data sync in my product?
Run one two-way sync per customer between that customer's CRM or ERP and a database your product already uses, such as Postgres. Your application reads and writes ordinary tables, and the sync carries changes in both directions. Stacksync manages the connection, API rate limits and failed writes for each sync, so your team does not maintain a connector per customer.
How do I let my customers connect their Salesforce, NetSuite or Snowflake data to my product?
Have the customer's own admin authorize the connection to their Salesforce, NetSuite or Snowflake account, for example through OAuth for Salesforce or token-based authentication for NetSuite, and create that customer's sync from a shared configuration. Stacksync holds the resulting credentials, so your application does not store them. The sync maps the objects and fields your product needs into your database, in a schema or database you choose for that customer, and only mapped fields sync. The authorization screen your customers see depends on the connector, so check it for each system you plan to offer during a proof of concept.
How is embedded two-way sync different from a unified API?
A unified API gives your code one request format that it calls for every read and write, while embedded two-way sync keeps a copy of each customer's records in your own database and keeps it current in both directions. With sync, reads are local queries and writes are row changes. Many teams use both: sync for bulk reads and updates, and direct API calls for requests that need an immediate response.
What are alternatives to Paragon for syncing custom objects across Salesforce, HubSpot and NetSuite?
Alternatives to Paragon include unified APIs such as Merge, integration infrastructure such as Nango, embedded iPaaS such as Workato Embedded, and embedded two-way sync with Stacksync, which syncs Salesforce custom objects, HubSpot custom objects on HubSpot plans that include them, and NetSuite custom records. Writes to NetSuite custom objects are enabled on request. Paragon's documentation (checked September 2026) describes it as integration infrastructure: your users connect their apps through its Connect SDK, Workflows and ActionKit run integration logic and actions, and Managed Sync pipes data from those apps into your product. Run your customers' custom objects through each option in a proof of concept.
Our AI agents keep hitting Salesforce API rate limits. Should we sync each customer's Salesforce into Postgres instead?
Yes, for reads: syncing each customer's Salesforce into Postgres moves agent reads off the Salesforce API, because agents query the local copy and the sync spends API calls only on changes. Smart API rate limits cap the requests each sync makes to the customer's org. For creates and deletes where the agent needs an immediate answer, call through the Stacksync API proxy and let two-way sync handle ongoing updates.
Can we create a new customer's sync by API instead of in the dashboard?
From the Pro plan up, the Management API and configuration as code for syncs let your backend create and update each customer's sync from one template. Confirm during scoping how each customer authorizes their connection, because their own admin completes that step. Workflow configuration as YAML or JSON files is available on every plan.
What happens when a write back to a customer's CRM fails?
The failed record appears in the Issues dashboard with the error the customer's system returned, for example a validation rule. You can retry it after the cause is fixed, revert it to the other system's value, or ignore it. Bulk actions and API-based resolution are available for handling issues at volume.
How is embedded sync priced across many customers?
Stacksync pricing is based on active syncs and records in sync. White-label use is an Enterprise feature, and Enterprise plans are quoted with volume-based discounts, so embedded deployments go through sales rather than self-serve plans. Reselling Stacksync under your own brand is a separate commercial program, the OEM track on the partners page.
