Combined vs Merge Unified API: SQL datasets or normalized integrations?

Choose the data contract your product needs

A product that supports several CRMs benefits from a consistent integration interface. A team asking questions across its own CRM, billing, and support systems benefits from a queryable dataset. We build Combined for the latter path. The useful comparison with Merge Unified API is how data reaches your application and which abstraction makes the remaining work easier.

See Merge's architecture, supplemental data, and Unified pricing for the matrix's vendor facts.

Normalization is a real advantage when your product needs it

Merge handles provider authentication, scheduled synchronization, and normalization into Common Models. Your application embeds its connection flow, stores account tokens, and consumes the API. Supported writes are also part of the architecture. This is useful when your feature should work across multiple providers behind a consistent model. See Merge's architecture reference.

Merge extends Common Models with Remote Data, authenticated passthrough, Field Mapping, and other supplemental options. Assess the specific field and plan you need. See its supplemental-data guide.

Merge's Unified API MCP server exposes API operations using a Linked Account and authorized scopes. You can evaluate that existing server when your agent needs Common Model operations.

Merge also offers Agent Handler for agent tool calling, with end-user or group authentication and scoped tool packs. Include that product if application operations are part of your evaluation. It is a different buying question from consuming Unified API records.

Combined gives the agent a managed SQL surface over the source datasets you select. It suits analysis where your business needs an explicit join, its own metric definitions, and inspected source freshness. Its 1,125 connectors include desktop-generated connections; a connector count alone does not establish the fields, object coverage, or connection route for your workload.

Test common-model portability and one awkward field

Start with a small customer list and a field that is meaningful to your product but is not universal: deployment region, renewal risk, implementation owner, or a custom account segment. The evaluation should show whether a standard model reduces work and how you handle the exception.

1. Define a target result with five fields: customer ID, name, owner, the custom property, and open-case count. Write down which values are required and which may be unknown.
2. For Merge, map that result to the relevant Common Models. Identify any field needing a supplemental route and verify it on your intended integration and plan.
3. For Combined, discover the actual CRM and support datasets, inspect the fields, and document the account mapping. Aggregate support records before joining.
4. If you have two authorized CRM test providers, repeat the mapping for both. Otherwise, inspect the second provider's schema documentation and mark that part as a design review, not a tested connection.

Build a customer summary from the granted CRM and support sources.
Return customer ID, name, owner, the available implementation-status
field, and open-case count. Discover schemas first. Show how each output
field maps to source fields. Preserve customers without cases, and mark
missing custom values unknown. Include SQL, source freshness, and any
mapping choices that would change if we switched CRM provider.

Score the amount of provider-specific code, completeness of required fields, stability of identifiers, and ownership of the analytical query. A common shape can make a customer-facing integration easier. A direct SQL calculation can make internal business analysis easier. The better choice is the one that simplifies the part of the product you will maintain every week.

Check the fields and budget before expanding

Merge Unified's pricing page organizes usage around production Linked Accounts and distinguishes plan capabilities such as custom fields and configurable sync frequency. Include the tier needed for your actual data requirements. For Combined, estimate initial and changing records using the MAR definition and pricing.

Choose Merge Unified when normalized integrations across your customers' providers are central to your product. Choose Combined when the immediate outcome is useful SQL-backed answers across your business systems, with ingestion, storage, discovery, and scoped agent access already connected. Evaluate one awkward real question before scaling to the rest of your stack.

Sources and further reading

Explore the documentation behind this guide. Product details checked on September 10, 2026.

• Combined MCP tools and Source grants
• Combined SQL interface
• Combined connector availability
• Combined pricing and MAR
• Merge Unified architecture
• Merge supplemental data
• Merge Unified API MCP
• Merge Agent Handler overview
• Merge Unified pricing