How to Sync Data Between Two Platforms (Even With No API)

Every business past a certain size runs on tools that do not talk to each other. The CRM does not know what the billing system knows, the ATS does not know what the VMS knows, and somebody on the team spends an hour a day retyping records from one screen into another.

Connecting two platforms is one of the most requested automation projects I build as a freelance automation developer, and it is also one of the most misquoted, because "sync our systems" can mean anything from a 30-minute Zapier setup to a two-way integration with conflict resolution. This guide lays out the four ways to connect two platforms, what each one costs in 2026, and how to tell whether you actually need sync at all, or ETL.

The four ways to connect two platforms

Work down this ladder in order. Each step down adds capability and cost, so stop at the first rung that solves your problem.

1. Native integration

Check both platforms' integration marketplaces first. If HubSpot already ships a QuickBooks integration that maps the fields you care about, use it. Native integrations are maintained by the vendors, survive API changes, and cost nothing beyond the subscription.

They fail you in two ways: the integration exists but does not map the fields you need, or it syncs on the vendor's schedule instead of yours. When you find yourself exporting CSVs to work around a native integration's gaps, move down a rung.

2. iPaaS: Zapier, Make, or n8n

Integration platforms give you prebuilt connectors for thousands of SaaS tools and a visual builder for the logic between them. For standard tools and modest volume, this rung solves most connection problems in days, not weeks.

The trap is pricing. Zapier and Make charge per task or operation, which is fine at 500 syncs a month and painful at 50,000. Self-hosted n8n removes per-task pricing entirely: you pay for a small server and own the instance. I cover the trade-offs in detail in my n8n vs Make vs Zapier guide, and migrating an expensive Zapier setup to self-hosted n8n is one of my most common fixed-price projects.

An iPaaS stops being the right tool when your logic outgrows the visual builder: multi-step conflict rules, per-field merge decisions, or throughput that needs real concurrency.

3. Custom API sync

A small service, usually Python, that talks to both platforms' REST or GraphQL APIs and keeps chosen records consistent. This is the rung where "connect our systems" becomes engineering, and where the reliability features that iPaaS tools half-deliver get built properly:

• Field mapping that handles the two platforms disagreeing about what a "contact" or a "placement" is.
• Idempotency keys so a retried request never creates a duplicate record.
• A retry queue for failures, with exponential backoff, instead of silently dropping a record because one API returned a 500.
• A change log so you can answer "why did this field change" six months later.
• Alerts on silence. The worst failure mode of any sync is not an error, it is zero records moving while everyone assumes it works.

A one-way custom sync typically runs $300 to $1,200 fixed. Two-way runs $800 to $2,500, and the next section explains why the price doubles.

4. No API at all: browser automation or private APIs

Plenty of platforms your business depends on offer no public API: legacy portals, government systems, and a remarkable share of staffing industry tools. Two escape hatches work.

Browser automation. A Playwright bot logs in, navigates, and reads or enters data exactly as a person would, on a schedule, with screenshots as an audit trail. Slower and more fragile than an API, but it works on anything a human can use.

Private API reverse engineering. The platform's own web app talks to a backend API; open the network tab and it is right there. Building against that private API is faster and far more stable than driving the UI. I wrote up the technique in reverse engineering private APIs.

I usually quote both options after a feasibility check, because the right choice depends on the target's protection and how often its UI changes.

One-way push vs two-way sync

Most projects that arrive as "we need two-way sync" are actually a one-way push: system A is the source of truth, system B needs a current copy. Be honest about which one you need, because the difference is the largest cost driver in the whole project.

A true two-way sync must answer questions a one-way push never faces:

1. Conflict resolution. The same contact was edited in both systems since the last sync. Which edit wins? The answer is either a source-of-truth rule per field or a merge policy, and someone from the business has to sign off on it.
2. Loop prevention. A syncs to B, B's webhook fires, B syncs back to A, forever. Every two-way sync needs origin tracking to break the loop.
3. Deletes. Does deleting a record in one system delete it in the other, archive it, or flag it for review? Silent delete propagation is how sync projects destroy data.

If a vendor or freelancer quotes two-way sync without asking about conflicts, deletes, and loops, they have not built one before.

Webhooks vs polling

The production answer is both: webhooks for freshness, plus a reconciliation poll every few hours that compares record counts and catches anything the webhooks dropped. Running that scheduler reliably is its own topic; my guide to running scheduled jobs in production covers the monitoring side.

When you need ETL instead of sync

Sync and ETL get conflated constantly, and the confusion is expensive because they are optimized for opposite things.

Sync keeps two operational systems consistent so people can work in either one. Record-level, near real time, bidirectional logic.

ETL (extract, transform, load) collects data from several sources on a schedule, cleans and reshapes it, and loads it into one place built for queries: PostgreSQL, BigQuery, or a spreadsheet the finance team lives in. One direction, batch-oriented, and the transform step is where the value is: deduplication, joining customers across systems, normalizing the five different ways your tools write dates.

The tell: if the goal is "reporting across our tools" or "one dashboard with everything", you need ETL, not sync. If the goal is "stop retyping records between tools", you need sync. Plenty of businesses need both, and they share infrastructure, which is why hiring one automation developer for the pair beats hiring two vendors.

For standard SaaS sources, managed connectors like Fivetran or Airbyte are worth pricing first. Custom Python ETL wins when your sources include scraped websites, no-API platforms, or transforms the managed tools cannot express, which in my project queue is most of the time.

What integration work costs in 2026

Senior freelance rates run $30 to $80 per hour; my own rate starts at $25 per hour and every project gets a fixed quote within 24 hours. The full rate breakdown and engagement options are on my automation hiring page.

A real example: syncing staffing platforms

The clearest case I work in is the staffing industry, where recruiters submit candidates from their ATS into client VMS portals by hand, hundreds of times a week. The platforms do not integrate, half the VMS tools have no public API, and the manual copy-paste step is where errors and lost hours concentrate. That exact problem, and the sync architecture that removes it, is written up in the ATS to VMS integration gap, and productized as my ATS and VMS data sync service.

The pattern generalizes: any pair of systems where people retype records is a sync project waiting to be scoped.

Decision checklist

Before you brief anyone, including me, answer these six questions. They determine the rung on the ladder and most of the price:

1. Which fields, exactly, need to move? List them.
2. One-way or genuinely two-way? Who wins a conflict?
3. Do both platforms have APIs? Check the developer docs, not the sales page.
4. How fresh does the data need to be: seconds, hours, or daily?
5. What volume: tens, thousands, or hundreds of thousands of records a month?
6. What should happen when a record fails to sync, and who gets told?

Need two systems talking to each other?

I build platform-to-platform sync, integrations, and ETL pipelines as fixed-price projects: field mapping, conflict rules, retries, and monitoring included, with the source in your repository. Describe the two systems and the fields through the contact form or hire me on Upwork, and you will have a scope and fixed quote within 24 hours. If you are still comparing options, my automation hiring guide covers 2026 rates and the questions worth asking any candidate.