--- title: "Merge vs. Unified.to: Which Unified API Should You Choose in 2026?" img: https://s3.us-east-2.amazonaws.com/unified-article-images/merge_vs_unified_which_unified_api_should_you_choose_in_2026-icon.png date: 2025-04-09T00:00:00.000Z tag: Product description: "Merge and Unified.to are both unified APIs, they normalize hundreds of B2B SaaS integrations into common data models, so you build against one schema per..." url: "https://unified.to/blog/merge_vs_unified_which_unified_api_should_you_choose_in_2026" --- # Merge vs. Unified.to: Which Unified API Should You Choose in 2026? ------ _April 9, 2025_ ![merge_vs_unified.png](https://s3.us-east-2.amazonaws.com/unified-article-images/merge_vs_unified_which_unified_api_should_you_choose_in_2026-0.png) _Updated Augus 2026_ Merge and Unified.to are both unified APIs: they normalize hundreds of B2B SaaS integrations into common data models, so you build against one schema per category instead of one integration at a time. Both detect change the same way, because there are only two ways to learn a record moved: the source pushes it, or you go look. What separates them is what happens next. Merge's syncs land in a database Merge owns, and every read you make is served from that copy. Unified.to routes each request through to the source and returns it without keeping anything. That difference, custody, explains almost every difference in what each platform charges you, what it gates behind a contract, and what you have to do to leave. The short version: choose Merge if your product reads the same records repeatedly and wants a stored copy to read from; choose Unified.to if you can't put customer data into a third party, need coverage across more than eight categories, or want cost that tracks usage instead of customer count. The rest of this post is why. This post was written for Unified.to. It compares the two using each platform's own published documentation, pricing pages, API references, and contract terms. Where a claim can't be traced to one of those, it isn't here, and where Merge is the better choice, it says so. --- ## TL;DR: Merge vs. Unified.to | Dimension | Merge | Unified.to | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Data custody | Stores normalized customer data until you request deletion | Stores no customer data at rest | | OAuth custody | Merge Link handles the OAuth and credential exchange | You register your own OAuth app per provider before production | | Billing unit | Per Linked Account: $650/mo for 10, $65/mo each after (Launch) | Per API call: 750,000/mo for $750 (Grow). Connections unlimited on every plan | | Published pricing | Launch only. Professional and Enterprise are contract-based | Grow, Pro, and Scale all published | | Entry tier, in each vendor's words | Launch: "for early-stage startups that want to build a proof of concept" | Grow: "for production applications with growing customer usage" | | Sync frequency | Daily is standard on Free and Launch; faster requires a customised Professional/Enterprise plan. Highest setting varies wildly by integration (5 min on OneDrive, 1 day on Box) | Virtual webhook interval configurable, down to one minute on paid plans; native webhooks fire on source events | | Deletion detection | Native, free, where the source supports it. Enhanced is a paid add-on that runs every three days | Deleted events on native webhooks where the source supports them. No equivalent to Enhanced | | Sync to your own database | Destinations: closed beta, Professional or Enterprise, Postgres, file storage category (July 2025) | Database Sync: seven databases, every category, included on every plan | | Rate limits | 100 / 400 / 600 per minute, **per Linked Account**, so aggregate throughput grows with your customer count | 5,000 / 7,500 / 10,000 per rolling 60 seconds, **shared per workspace**. Provider limits are usually the real ceiling | | Categories | 8 (Chat currently has one integration) | 32 | | Integrations | 240+ (per Merge's integrations page) | 719 | | Best for | High-volume repeated reads, outage-resilient reads from a stored copy, teams that want to defer OAuth setup | Products that can't put customer data in a third party, multi-category coverage, usage-aligned cost | --- ## What is actually different between Merge and Unified.to? The architectures are fundamentally different, and the difference is custody: Merge stores a normalized copy of your customers' data and holds their [OAuth](/embeddedauth) grants. Unified.to holds neither. The difference isn't polling. Both platforms poll where the source has no [webhooks](/blog/replacing_polling_with_unified_webhooks_and_virtual_streams) and push where it does, so any comparison built on one polling and the other not is describing marketing rather than either product. The [architectural split](https://unified.to/blog/pass_through_vs_sync_based_unified_apis_architecture_trade_offs_in_2026) is what happens to a record after it's fetched. On Merge it lands in a database Merge owns, and every read you make afterward comes out of that copy rather than the source. On Unified.to it goes to you and nothing stays behind. Here is [Merge's own architecture reference](https://docs.merge.dev/merge-unified/reading-data/webhooks/overview), describing the three parties in a Merge integration: > "**Merge** handles authentication with third-party platforms, runs syncs on a schedule, normalizes data into Common Models, and delivers webhooks when data changes." And, in the same document: > "**The third-party platform** (BambooHR, Greenhouse, HubSpot, etc.) is the source of truth. Merge reads from and writes to it on your behalf." Merge calls the third-party platform the source of truth, which is another way of saying Merge's copy isn't. Unified.to routes each request to the source at request time and streams the response back without retaining it. Only minimal operational metadata such as IDs and timestamps is stored. Custody buys Merge real things, and they're worth naming before the costs. A read against a stored copy is a database lookup: it returns in milliseconds, costs nothing per call, and never touches the source's rate limit. It also survives the source going down. If HubSpot has an outage, Merge keeps serving reads from its copy. A platform that routes every read through to HubSpot does not. Those advantages aren't features Merge bolted on; they fall out of holding the data, and no pass-through architecture can match them. The cost is the mirror image, and it's just as inherent. What you read is what was true at the last sync, so freshness is bounded by your sync plan wherever the source has no webhooks — and, as the pricing section shows, on Merge's entry tiers webhooks aren't available at all, so freshness there is bounded everywhere. A copy of someone else's data drifts. That's not a bug in Merge's implementation, it's what copies do. Once you see custody as the variable, Merge's structure stops looking arbitrary. Nearly every capability Merge charges extra for is a remedy for holding the data: - **Field-level scopes** ("field-level scopes for enhanced data minimization," in Merge's words) limit what lands in Merge's database. All plans get Common Model Scopes; editing field-level scopes requires Professional or Enterprise. - **Enhanced deleted data** reconciles Merge's copy against the source when the source doesn't announce deletions. Paid add-on, annual Professional or Enterprise. - **Merge's** [**MSA**](https://www.merge.dev/legal/msa) grants Merge "a limited license during the Term to use Customer Data to provide and maintain the Service" (Section 4.1), and commits that Merge "will not, and will not allow any third party to, use Customer Data to train, fine-tune, or improve any AI" (Section 4.5). That's a real commitment, and it's necessary because there is stored Customer Data to make a commitment about. - **Merge's MSA** obligates Merge to delete Customer Data on written request at termination (Section 5.3). None of those are criticisms of Merge's engineering. They're consequences of the model. A platform that stores nothing has nothing to scope, nothing to reconcile, nothing to promise about, and nothing to delete. What Merge stores does vary by category. For File Storage, Merge's help center says it holds metadata and permissions but not file contents, fetching those on demand. --- ## Do Merge and Unified.to get data the same way? Both platforms push where the source supports webhooks and poll where it doesn't — with one tier caveat on Merge's side, covered below. That part is table stakes, not a differentiator, and any comparison claiming one polls and the other doesn't is describing marketing rather than either product. What differs is where the polled data lands. Merge runs two webhook types. Third-party webhooks are configured in the source platform so it pushes changes into Merge, which Merge says gives you real-time updates regardless of the rate at which Merge syncs data. Merge then sends its own webhooks to your app, carrying the affected data model. Where a source has no webhook support, Merge falls back to its scheduled sync. One thing Merge's docs are explicit about, and it matters: third-party webhooks are available only on Professional and Enterprise plans. On Free and Launch, there is no push path at all — the source-to-Merge leg is scheduled sync only, which on those tiers means Daily. Merge does something genuinely useful here, on the tiers that have it: on supported integrations its Automatic Webhooks feature sets those third-party webhooks up for you, with no configuration required from you or your end user. Unified.to's own comparison table concedes that native webhooks "may require additional configuration on other platforms." If your customers would otherwise have to paste a listener URL into their HRIS, that difference is real — provided you're on Professional or Enterprise, since that's where third-party webhooks live. Unified.to works the same way with different names. Native webhooks relay the source's own events. [Virtual webhooks](/blog/unlock_real_time_data_with_virtual_webhooks) poll on an interval you set and dispatch only when they find changes. Unified.to's docs are direct about why virtual webhooks exist at all: "Most APIs do not support webhooks natively." So both are fast where the source is fast and scheduled where it isn't. The mechanism is shared; the destination isn't. Merge's poll writes to Merge's database, and your read comes back out of it later. Unified.to's poll goes straight to your endpoint or your database and leaves nothing behind. Two things follow from that. **Merge tells you to keep polling anyway.** Its architecture reference recommends "a combination of webhooks and polling," and its syncing guidance says not to rely entirely on notification webhooks, because webhooks fail from downtime or failed processing. Merge redelivers with exponential backoff and still recommends calling your sync functions every 24 hours, using `modified_after` to fetch only what changed. Merge's File Storage guide goes further: third-party webhooks may have coverage gaps or be hit by third-party outages, and consistent polling is the most comprehensive way to capture all relevant changes. **Daily is Merge's standard sync frequency on Free and Launch.** Merge's help centre states it plainly: Free and Launch plans get the standard Daily frequency, and faster frequencies require a customised Professional or Enterprise plan. What "faster" means, though, varies enormously by integration — and Merge publishes a per-integration table that shows the spread. On OneDrive, the Highest setting syncs every 5 minutes. On Box, in the same file-storage category, the Highest setting is 1 hour for one model and 1 day for the rest. Same tier, same category, and the delivered cadence differs by orders of magnitude. The intervals are integration-specific, and Merge says the highest frequencies are tuned to each third party's rate limits — so "Highest" is a label, not a guaranteed cadence. The plan mapping is the part that matters for a buyer: on Free or Launch, your data is a day old. Sub-daily freshness requires a customised Professional or Enterprise plan, and even then, how fast you actually get depends on the specific integration — anywhere from five minutes to a day. Freshness, in other words, is one of the things gated behind the contract, and it's not uniform once you're there. Unified.to publishes its side too: on paid plans, virtual webhook intervals go down to one minute, and native webhooks fire on the source's own events. **Pro tip:** before you set a one-minute interval on Unified.to, model the bill. Every run that finds data is a billable call. Runs that find nothing are free, but a busy connection polled every minute adds up. Match the interval to how fast the data actually needs to arrive, not to how fast it can. ![unified-vs-merge-architecture.png](https://s3.us-east-2.amazonaws.com/unified-article-images/merge_vs_unified_which_unified_api_should_you_choose_in_2026-1.png) --- ## How much does Merge cost compared to Unified.to? Merge charges $65 per Linked Account per month above its 10-account base. Unified.to charges roughly $0.001 per API call and includes unlimited connections on every plan. Both platforms define the connection identically. Merge calls it a Linked Account: one customer connected to one integration. Unified.to calls it a customer connection and says so explicitly: "In some platforms, a customer connection is called a linked account." A customer using three integrations is three units on either platform. The unit Merge charges $65 a month for is the unit Unified.to includes without limit on every plan. **Merge Launch**, as published: - First 3 production Linked Accounts free - $650/month for up to 10 total - $65/month per Linked Account after that - "Contact us for volume discounts" **Unified.to**, as published: | Plan | Monthly | Included calls | Overage | | ----- | ------- | -------------- | --------------- | | Grow | $750+ | 750,000 | $1.00 per 1,000 | | Pro | $1,500+ | 2,000,000 | $0.75 per 1,000 | | Scale | $3,000+ | 6,000,000 | $0.50 per 1,000 | Here's the part nobody publishes: **both models collapse to a single multiplication.** Merge's base fee disappears into its per-account rate, and each Unified.to plan prices its included calls at exactly that plan's overage rate. So Merge is $65 times your connections, and Unified.to is your calls times your rate. (The two [pricing models scale very differently as you grow](https://unified.to/blog/unified_apis_usage_based_vs_per_connection_pricing_for_integrations); the break-even below is where they cross.) Which means the break-even is a ratio, and it's the same whether you have 12 connections or 12,000: | Merge rate | Break-even vs. Grow | Break-even vs. Scale | | --------------------------------------- | -------------------------------------- | -------------------------------------- | | Launch, $65 per connection | 65,000 calls per connection per month | 130,000 calls per connection per month | | Professional, about $104 per connection | 104,000 calls per connection per month | 208,000 calls per connection per month | The Professional figure comes from the one public Professional price: a [Merge Professional bundle on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-jgjtrfz5rysi4) at $25,000 for a 12-month contract covering 20 Linked Accounts. That works out to about $104 per account per month. Worth noting what that bundle includes: Daily Sync Frequency. The only public Professional price Merge has is for daily sync — the faster cadences that need a customised plan aren't in any published number. **What 130,000 calls per connection per month looks like:** roughly 3 API calls per minute, per connection, continuously. Below that, Unified.to is cheaper. Above it, Merge is, and there's a better answer than either, covered further down. Four caveats that cut in both directions: - **$65 is a list price.** Merge's pricing page invites you to "contact us for volume discounts," so real per-account rates likely fall with size. The break-even moves with whatever rate you're quoted, in a straight line: at $40 a connection it's 40,000 calls against Grow, at $100 it's 100,000. Divide your quoted rate by the per-call price and you have your own number. - **Unified.to discounts too.** Annual billing is 17% off, and there are startup discounts plus accelerator programs. - **Merge doesn't charge for churn.** Launch is billed in arrears on the net-average daily count of active Linked Accounts from the prior month, so a customer who connects and disconnects mid-month doesn't cost a full month. Every break-even above assumes static counts. - **Above Launch there's no public number to compare.** Professional and Enterprise are contract-based. - **Merge doesn't meter webhooks.** Unified.to does: every successful dispatch is a billable API call, whether it went to your endpoint or your database. On Merge, webhook volume costs nothing. If your product is event-heavy rather than read-heavy, that shifts the math in Merge's favour, and it isn't captured in the break-even above. --- ## What does it look like at scale? Three things change as you grow, and they don't all point the same way. **Cost is linear on both, so the break-even holds at any size.** Nothing kicks in at 500 customers that didn't apply at 50. Merge is your connection count times its per-account rate; Unified.to is your call volume times your rate. Which one wins depends on how hard each connection gets read, not on how many you have. **Throughput moves in Merge's favour.** Merge's rate limits are per Linked Account: 100 requests per minute on Launch, applied to each customer separately. [Merge's docs are explicit](https://docs.merge.dev/merge-unified/hris/merge-api-basics/rate-limits) that with 10 customers, the limit applies to each one. So your ceiling grows every time you sign someone. Unified.to's limits are per workspace, a rolling 60-second window at 5,000 requests on Grow, shared across every connection you have. They cross at roughly 50 connections, and past that Merge keeps climbing while Unified.to's ceiling stays put. One noisy customer also can't starve the others on Merge. **On Unified.to, the provider is usually your real ceiling anyway.** Their docs say platform limits are "the primary limiting factor," and a 429 means the source said no, not that Unified.to did. Reading through to the source means inheriting HubSpot's budget. Merge's stored copy insulates reads from that entirely, which is the clearest thing custody actually buys you. **The resolution isn't picking the other vendor. It's changing how you read.** Past the break-even, both the cost curve and the rate limit are telling you the same thing: stop making per-record API calls for data you already have. Database Sync writes changes into your database, your app reads locally at no marginal cost and no rate limit, and Unified.to bills the change dispatches rather than your reads. That's the architecture answer to scale, and it's on the entry plan. --- ## Which Merge plan do you actually need? Merge publishes a price for one plan, and describes that plan as a proof of concept. That's not an interpretation. It's Merge's pricing page, verbatim: | Plan | How Merge describes it | Price | | ------------ | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ | | Launch | "For early-stage startups that want to build a proof of concept." Footer: "Basic functionality included" | $650/month, published | | Professional | "Most popular." "For companies that want to power deep integration use cases." Footer: "The best fit for most companies" | "Contract-based pricing." Get a demo | | Enterprise | "For large companies that want white-glove security, support, and infrastructure" | "Contract-based pricing." Get a demo | What Merge lists on the Professional card: custom fields, field-level scopes for enhanced data minimization, custom sync frequencies, 60-day access to developer sandboxes, and go-live support packages. Merge's help centre notes that Merge-owned sandbox accounts are available to Professional and Enterprise customers; the pricing page splits the two, giving Professional 60-day sandbox access and Enterprise unlimited access. Enterprise adds Audit Trail, premium go-live support, unlimited sandboxes, a dedicated account manager with a shared Slack channel, and support and uptime SLAs. For comparison, Unified.to describes Grow, at $750, as "for production applications with growing customer usage," and its plan comparison table marks Grow as Production Capable. Which means the headline comparison most buyers run, Merge's $650 against Unified.to's $750, is generous to Merge. It prices Unified.to's production tier against the tier Merge itself calls a proof of concept. The plan Merge calls "the best fit for most companies" has no public price at all. --- ## What happens when a record is deleted at the source? Neither Merge nor Unified.to can detect a deletion the source system doesn't announce, unless it holds a stored copy to compare against. That limit is real on both sides, and it matters more than the tier differences. Detecting a deletion means noticing something is absent. You can't poll for absence. You have to compare what's there now against what was there before, and that requires a baseline. Merge has one, so Merge can sell the fix. From [Merge's pricing page](https://www.merge.dev/pricing/unified) and [deletion detection docs](https://help.merge.dev/en/articles/5392795-deleted-data-detection): | Merge feature | What it covers | Availability | | --------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- | | Native deleted data | "Detect deleted data when supported by a third-party platform" | Free, all plans | | Enhanced deleted data | "Added functionality for detecting deleted data when it is not natively supported by a third-party platform" | Paid add-on, annual Professional or Enterprise | Merge's docs also state the cadence of the paid job: "The process of detecting the deleted records will run on a periodic basis of every three days." [(source)](https://help.merge.dev/en/articles/5392795-deleted-data-detection) Unified.to draws the same line with the same conditional. Native webhooks support "created, updated, and deleted events if the integration supports them." Virtual webhooks, per Unified.to's own comparison table, "mainly support created and updated events." There is no Unified.to equivalent to Enhanced deleted data, because there is no stored copy to reconcile against. Two honest conclusions follow. **For pass-through reads on Unified.to, deletion detection doesn't arise.** A deleted record isn't returned by the source, so it isn't in the response. No job to run, nothing to reconcile. **For any copy, including one in your own database, the gap is real.** If the source doesn't announce deletions, only Merge offers a mechanism, it's a paid add-on on a contract tier, and it runs every three days. This shows up in buyer feedback. Cost at scale is the most common complaint in Merge's G2 reviews, and the deletion add-on is named specifically: one reviewer's only dislike is "not having the ability to sync deleted entities from ERPs without purchasing the Delete data plan separately." Keep it in proportion, though: the same reviews praise Merge's documentation and support repeatedly, and the platform holds a strong overall rating. The critique is "it gets expensive as you grow," not "it doesn't work." --- ## Can you sync data into your own database? Both platforms can write normalized data into your own database, but Merge's Destinations is in closed beta on Professional and Enterprise, while Unified.to's Database Sync is included on every plan. **Merge Destinations** streams normalized data into your own database instead of Merge's primary store. As of Merge's July 2025 announcement, it's in closed beta on Professional or Enterprise, supports Postgres, and covers the file storage category. Merge said it planned to expand to more storage platforms and categories. Either way, Merge still ingests, processes, and normalizes the data in its own infrastructure before streaming it out: Destinations changes where data lives long-term, not whether Merge processes it. **Unified.to Database Sync** writes to MongoDB, MySQL, Postgres, MSSQL, MariaDB, Supabase, or Snowflake, across every category, and it's on Grow. Mechanically it's a webhook with a database as the destination instead of a URL, which is visible in the API: the webhook object carries `db_type`, `db_url`, and `db_schema` alongside `hook_url`. You can send to both. Neither platform writes to S3 or BigQuery as a sync destination. Both offer them as integrations your customers can connect, which is a different thing: an integration is a system you read from, a destination is where your normalized data lands. **Here's why this matters for cost.** The break-even above says Merge gets cheaper past roughly 65,000 reads per connection per month. But if your app is doing that many reads, the answer isn't to buy a platform that stores your data. It's to stop paying per read. Database Sync bills like a webhook: each page of data dispatched is one API call, and runs that find nothing are free. Your cost driver moves from _reads your app makes_ to _changes at the source_. An app doing 200,000 reads a month against its own database might generate a few thousand billable sync dispatches. The reads themselves cost nothing. The trade is real and you should take it deliberately. Once you run Database Sync you hold a copy, and a copy can drift. Deletions propagate where the source announces them (a `deleted` event removes the row from your database) and don't where it doesn't. The problem doesn't disappear. What changes is that the copy sits in your database, under your retention policy and your deletion, and Unified.to still stores nothing. --- ## Who holds your customers' OAuth grants? On Merge, your end users authorize through Merge Link and Merge handles the OAuth exchange. On Unified.to, you register your own OAuth app with each provider before you go to production. This is a real Merge advantage on time to first integration, and it deserves to be said plainly. From [Merge's concepts doc](https://docs.merge.dev/merge-unified/concepts): "Merge handles the OAuth and credential exchange." You embed Merge Link, your user picks an integration and signs in, and you're live. No developer app registration with BambooHR, then Greenhouse, then HubSpot. Unified.to asks for that work up front. From its OAuth documentation: "To start using an integration that supports OAuth 2 within Unified.to, you'll first need to register your app with the third-party system to get your OAuth 2 credentials, which include a client ID." Unified.to's own credentials are available for testing, but the docs are clear about production: "when you're ready to go live, it's important to switch to your app's OAuth 2 credentials. This ensures that your customers will see your branding during the authorization process." So the trade is speed against ownership. Merge gets you to a working integration faster. Unified.to puts your name on the consent screen your customers see, and the OAuth grant is issued to your application. On Unified.to's Pro plan and above, you can also keep OAuth credentials in your own AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, or HashiCorp Vault rather than in Unified.to's database. --- ## What are the security and compliance postures? Both platforms run on AWS with encryption at rest and in transit. Merge adds a second application-layer encryption on PII fields and says its own security team runs penetration testing annually. Unified.to encrypts its minimal operational metadata at rest with AES-256, uses TLS 1.2+ in transit, and undergoes annual third-party penetration testing. | | Merge | Unified.to | | ------------------------ | ------------------------------------- | -------------------------------- | | SOC 2 Type II | Yes | Yes | | ISO 27001 | Yes | Not listed | | HIPAA | Yes | Yes, BAA on Scale | | GDPR | Yes | Yes | | CCPA / CPRA | Yes | Yes | | PIPEDA | Not listed | Yes | | Customer-managed secrets | Not listed | Pro and Scale | | IP allowlisting | Not listed | Pro and Scale | | SAML SSO | Not itemized on Merge's plan cards | Pro and Scale | | Data regions | AWS Virginia, Stockholm, or Singapore | North America, Europe, Australia | Merge holds the broader certification list, including ISO 27001. Unified.to's [no-storage model](https://unified.to/security) removes end-customer PII persistence from its environment, which reduces what a security review has to cover on the Unified.to side. Both can support an enterprise security review. The architectures shape what that review has to examine. One nuance on data regions: since Unified.to doesn't store customer data, its regions govern where requests are processed rather than where data lives. For GDPR, processing location is its own question. --- ## What happens when you leave? Leaving Merge requires a written request to have your customers' data deleted. Leaving Unified.to doesn't, because there's nothing stored to delete. Merge's [Master Services Agreement](https://www.merge.dev/legal/msa), last updated July 1, 2026, is explicit in Section 5.3: > "Upon termination or expiration of this Agreement for any reason, Merge will, **upon written request**, delete all Customer Data processed on behalf of Customer during the Subscription Term." Termination doesn't trigger deletion. A request does. Merge also exposes a per-category `/delete-account` endpoint so you can remove Linked Accounts yourself, and you'd rotate or revoke org-level access keys on the way out. The friction isn't complexity. It's that nothing happens unless you ask. Merge's help center makes the same point about individual accounts, and it's the sentence worth reading twice before you sign: revoking an integration will not delete existing data for the Linked Account. It only prevents new data from being created. Merge's own data storage documentation states that customer data and credentials are stored indefinitely until actively deleted by the Merge customer. Two related terms, both from Merge's own materials. Subscription length is set on the Order Form, and the MSA specifies no minimum term. Merge's help center states that standard payment terms are annual prepayment, net 30, that Launch is billed monthly in arrears on net-average Linked Account count, and that Professional and Enterprise are billed per signed MSA. On Unified.to there is no synced dataset to extract or delete. Offboarding is contract termination and token rotation. For buyers, custody is the thing to price into the decision. It extends past integration logic into the data and credentials a platform holds after billing stops. --- ## How do Merge and Unified.to support AI agents and MCP? Both platforms expose normalized data to AI agents over MCP. What the agent sees depends on custody. Merge offers two paths. Its Unified API ships an MCP server for connecting agents to the Merge API, which serves Merge's stored, normalized data at whatever cadence your plan syncs. Agent Handler is a separate product, sold separately, giving agents tool access to third-party systems over MCP. Unified MCP exposes Unified.to's normalized objects to MCP-compatible clients (Anthropic, OpenAI, Google Gemini, Cohere, and others). Tool calls execute against the source at request time, so an agent reading from a deep enterprise system like Workday sees current state rather than a synced copy. All of Unified.to's integrations are reachable through one MCP URL, with connection-scoped permissions and tool filtering. For agents that read current customer context or execute writes needing immediate source-side confirmation, reading through to the source avoids the staleness window that comes with reading a copy. For agents doing heavy repeated analysis over the same records, reading a copy is faster and costs nothing per call. --- ## Should you choose Merge or Unified.to? The decision is custody, and the question underneath it is simple: do you want a vendor holding your customers' data and their OAuth grants? Every difference in this post follows from how you answer that — what's gated to a contract, what costs extra, whose name is on the consent screen, and what you have to do to get your customers' records back out. If your product reads the same records over and over, Merge's stored copy earns what it costs. Reads come back in milliseconds, cost nothing per call, don't touch the source's rate limit, and keep working when the source is down. That's a real case, and for a reporting or analytics product it's probably the right one. For everything else, Unified.to's bet is that the answer to the custody question is no — and the published pricing, the unlimited connections, and the zero-storage posture all follow from taking that position seriously. Tooling won't be the tiebreaker: both are strong. Merge's write stack is deeper than most comparisons admit (`/meta` field discovery, idempotency keys, async and bulk writes, JSONata field mapping), and Unified.to ships seven version-aware SDKs, embedded auth components, and an instant sandbox that needs no third-party account to start building. The decision sits above tooling, in custody. The two lists below are the same decision, itemized. **Choose Merge if:** - Your product does heavy, repeated reads over the same records (analytics, reporting, dashboards), where reads against a stored copy are fast and cost nothing per call - You want a first production integration live without registering a developer app with each provider - You need deletion detection for source systems that don't announce deletions, and can budget Merge's add-on for it on an annual Professional or Enterprise plan - Your read patterns tolerate your plan's sync cadence — daily on Launch, faster only on the Professional contract tier - Your workload is read-heavy analytics or reporting over the same records, where a stored copy is the point rather than a liability - Your compliance review accommodates a unified API vendor storing customer data as a sub-processor **Choose Unified.to if:** - You can't put customer data into a third party, or want it out of every enterprise security review - You need coverage across categories beyond Merge's eight - Your unit economics work better on usage than per connection, especially with many customers at moderate use, or a free tier - You want a published price on the plan you'll actually run in production - You want the OAuth grant issued to your application and your branding on the consent screen your customers see - You want custom fields, passthrough, unlimited connections, and database sync on the entry plan rather than gated to a contract tier --- ## Frequently asked questions **Is Merge or Unified.to cheaper?** It depends on calls per connection, not customer count. Merge Launch is cheaper below about 12 Linked Accounts, where its flat fee sits under Unified.to's $750 minimum. Above that, Unified.to is cheaper until each connection exceeds roughly 65,000 to 130,000 API calls per month, which is about 1.5 to 3 calls per minute continuously. **How much does Merge cost for 100 customers?** On the published Launch plan, 100 customers each connecting one integration is 100 Linked Accounts, which is $6,500 per month. At three integrations each, it's 300 Linked Accounts and $19,500 per month. Merge invites volume discount conversations, and above Launch its pricing is contract-based and not public. **Does Unified.to store customer data?** No. Unified.to fetches data from the source API per request and streams the response back without retaining it. Only minimal operational metadata like IDs and timestamps is stored. If you use Database Sync, the copy lands in your own database, not Unified.to's. **Which Merge plan do I need for production?** Merge describes Launch as being "for early-stage startups that want to build a proof of concept" and Professional as "the best fit for most companies." Custom fields, field-level scopes, custom sync frequencies, and developer sandboxes are Professional features. Professional pricing is contract-based and requires a demo. **Do Merge and Unified.to detect deleted records?** Both relay deletions where the source system announces them. Merge additionally sells Enhanced deleted data as a paid add-on on annual Professional or Enterprise plans, which detects deletions the source doesn't announce by reconciling its stored copy every three days. Unified.to has no equivalent, because it holds no copy to reconcile. **Can I sync Merge or Unified.to data into my own database?** Both offer it. As of Merge's July 2025 announcement, Destinations is in closed beta on Professional or Enterprise, supports Postgres, and covers the file storage category. Unified.to's Database Sync supports seven databases across every category and is included on every plan. **Does Merge only sync once a day?** On Launch, yes — Merge's help centre states Free and Launch plans get the standard Daily sync frequency. Faster cadences require a customised Professional or Enterprise plan, and even the Highest setting varies sharply by integration: 5 minutes on OneDrive, but 1 day on Box in the same file-storage category. So sub-daily freshness requires the contract tier, and how fast you actually get depends on the integration. **Do I need my own OAuth credentials?** On Unified.to, yes, for production. Its docs say to register your app with each third-party system and switch to your own credentials before going live, which puts your branding on the consent screen. On Merge, Merge Link handles the OAuth and credential exchange. --- ## Key takeaways - Merge and Unified.to both push where the source pushes and poll where it doesn't — though on Merge, third-party webhooks are a Professional/Enterprise feature, so Free and Launch are daily sync only. The deeper difference is custody: Merge stores your customers' data and holds their OAuth grants, and Unified.to holds neither. - Merge charges per Linked Account ($65/month above its 10-account base on Launch). Unified.to charges per API call and includes unlimited connections. Both collapse to a simple multiplication, and the break-even is 65,000 to 130,000 calls per connection per month, independent of how many connections you have. - Merge publishes a price for one plan and calls that plan a proof of concept. The plan it calls "the best fit for most companies" is contract-based. Unified.to publishes Grow, Pro, and Scale. - Neither platform can detect a deletion the source doesn't announce without a stored copy. Merge sells that reconciliation as a paid add-on, running every three days. Unified.to doesn't offer it. - Merge gets you to a first integration faster because Merge Link handles OAuth. Unified.to asks you to register your own app, which puts your name on the consent screen. - Merge's MSA, updated July 1, 2026, deletes Customer Data on written request at termination. Unified.to has nothing stored to delete. --- Custody is the decision. Everything else follows from it. [**Start your free 30-day trial**](https://unified.to/pricing) or [**talk to our team**](https://unified.to/contact) to see Unified.to in production. --- _Written for Unified.to by Mallory Greene._ _About the author: Mallory Greene writes about generative engine optimization (GEO) and B2B content strategy through her practice, Search Everywhere. She has covered unified APIs and integration infrastructure across Unified.to's technical content library. Based in Toronto._