Skip to content

Ampersand vs Merge vs Truto: Unified API Comparison (2026)

A deep-dive technical comparison of Merge, Ampersand, and Truto. Learn which unified API architecture scales best for enterprise B2B SaaS and AI agents in 2026.

Sidharth Verma Sidharth Verma · · 13 min read
Ampersand vs Merge vs Truto: Unified API Comparison (2026)

You are evaluating integration platforms because your engineering team is drowning in third-party API documentation, and your sales team is losing deals due to missing integrations. You have three names on your shortlist: Merge, Ampersand, and Truto. Each takes a fundamentally different architectural bet on how to solve the exact same problem—connecting your B2B SaaS product to the dozens of third-party tools your customers already use.

The math driving this evaluation is unforgiving. According to 2025 data from BetterCloud, organizations use an average of 106 different SaaS tools. That number sounds manageable until you look upmarket. Productiv's 2026 enterprise research reveals that large firms with 10,000+ employees run an average of 473 SaaS applications. Your product needs to play nicely with a growing chunk of that stack.

Integration is no longer an optional feature; it is a baseline requirement. According to the State of SaaS Integrations report, 60% of all SaaS sales cycles now involve integration discussions, and for 84% of software buyers, integrations are considered a "key requirement" or an outright dealbreaker. When a prospect asks, "Does this connect to our Workday instance?" and your answer is "It's on the roadmap," you have likely lost the deal. Why Truto is the best unified API for enterprise SaaS integrations covers this market shift in extensive detail.

To solve this, engineering leaders typically evaluate three distinct architectural approaches to unified APIs: Merge (the incumbent store-and-sync model), Ampersand (the code-first declarative pipeline), and Truto (the real-time, zero-retention proxy).

This guide breaks down those architectural bets, their pricing consequences, and what they mean for your engineering team, your compliance posture, and your unit economics at scale.

Architecture Showdown: Caching vs. Declarative vs. Real-Time

The most important decision you will make when choosing an integration platform isn't about feature checklists. It's about the data flow pattern—how data moves between your customers' SaaS tools and your application. Your choice here dictates your data latency, security posture, and infrastructure overhead.

Merge: The Store-and-Sync Cache

Merge operates on a polling architecture. It authenticates with the upstream provider (e.g., Salesforce, Workday, Greenhouse), polls the API at scheduled intervals, normalizes the data into a standardized schema, and stores a complete copy of that data in Merge's own databases. When your application queries the Merge API, you are querying Merge's database, not the live third-party system.

The Trade-off: The primary benefit is speed. Reads are incredibly fast because the data is already cached on Merge's infrastructure. You can efficiently pull only data that has been changed or created since your last sync using modified_after timestamps, which is great for batch processing.

However, the data is inherently stale. Your data is only as fresh as Merge's last sync cycle. If a user updates a contact in HubSpot, your application will not see that change until Merge completes its next poll. For use cases requiring strict real-time consistency—like updating a support ticket, triggering a synchronous payment, or fetching live inventory—this caching layer introduces race conditions. Furthermore, you now have a copy of your customers' sensitive data sitting on a third party's servers, drastically complicating your compliance posture.

Ampersand: The Code-First Pipeline

Ampersand takes a completely different approach. It functions more like a managed ETL (Extract, Transform, Load) pipeline configured via code. Ampersand explicitly states they are not a unified API; instead, they focus on standardizing patterns of interaction while allowing for deep customization.

Engineers write declarative amp.yaml manifest files that define how data should map between the third-party SaaS app and your own database. You define the API to connect to, the objects and fields you want to read or write, and the configuration options you want to expose to your customers. Ampersand then provisions the infrastructure to execute these syncs.

The Trade-off: You get deep, bi-directional syncs that write directly into your database schema, and credential ownership is built into the architecture. You own the OAuth keys, meaning switching platforms doesn't force customers to re-authenticate.

The cost is high engineering overhead. You are building each integration individually. There is no common data model across providers. If you need to list contacts from Salesforce and HubSpot identically, that normalization is entirely your responsibility. You own the mapping logic, you maintain the YAML files in your CI/CD pipeline, and you are responsible for handling schema migrations when upstream APIs change.

Truto: The Real-Time Proxy

Truto takes a third approach: a stateless, real-time execution engine. It uses zero integration-specific code. Instead, it relies on a generic proxy pipeline and declarative JSONata expressions stored as configuration data.

When you call GET /unified/crm/contacts, Truto resolves the integration mapping, translates your query into the provider-specific format (HubSpot's filterGroups syntax, Salesforce's SOQL, Pipedrive's query parameters), executes a live HTTP call to the upstream provider, maps the response back to the unified schema, and returns it to you immediately. No caching. No intermediate data storage.

flowchart LR
    A[Your App] -->|API Call| B{Integration Platform}
    B -->|Merge| C[Merge Cache<br>Periodic Sync]
    B -->|Ampersand| D[Direct API Call<br>Per-Provider Config]
    B -->|Truto| E[Real-Time Proxy<br>Unified Mapping]
    C --> F[Third-Party API]
    D --> F
    E --> F

Let's look closer at how Truto handles the real-time execution path:

sequenceDiagram
    participant Client
    participant Truto
    participant Upstream API (e.g., Salesforce)
    
    Client->>Truto: GET /unified/crm/contacts<br>Auth: Bearer token
    Note over Truto: 1. Resolve JSONata mapping<br>2. Check OAuth token expiry
    Truto->>Upstream API: GET /services/data/v59.0/query?q=...<br>Auth: Upstream OAuth token
    Upstream API-->>Truto: Raw native response
    Note over Truto: 3. Apply JSONata response mapping<br>4. Normalize rate limit headers
    Truto-->>Client: Unified JSON response

The Trade-off: You get absolute real-time data consistency and zero caching liability. The trade-off is that you are subject to the latency and availability of the upstream API. If the legacy SOAP API you are querying takes two seconds to respond, your Truto request takes two seconds. There is no local cache to fall back on if the upstream provider is experiencing an outage.

Handling the Enterprise Edge: Custom Fields and Objects

Every unified API comparison looks great until your first enterprise customer shows up with a Salesforce instance that has 200 custom fields, three custom objects, and unique validation rules nobody warned you about. How each platform handles this edge case is where the rubber meets the road.

Merge struggles with the enterprise edge. Because it relies on a rigid, lowest-common-denominator database schema to store cached data—a common hidden cost of rigid schemas—handling custom fields is notoriously difficult. Merge supports custom fields through its Field Mapping feature, but programmatically configuring these mappings is only available on Enterprise plans. On lower tiers, you can configure mappings manually through the dashboard, but scaling this per-tenant is unmanageable. When the unified schema fails entirely, Merge forces you to use their "passthrough" endpoints, which bypass the unified format entirely and force you to write provider-specific code. Truto vs Merge.dev: The best alternative for custom APIs provides a deeper look into this limitation.

Ampersand handles custom fields natively because it doesn't impose a common data model. You can read or write any object or field, standard or custom. You define exactly which fields you want in your amp.yaml manifest, and your end users can configure field mappings through embeddable UI components. This is powerful, but it requires manual engineering intervention to update declarative manifests for every unique enterprise tenant.

Truto solves the custom field problem using a three-level override hierarchy (Platform -> Environment -> Account) combined with JSONata.

Integration behavior in Truto is defined entirely as data. If a specific enterprise customer has a highly customized HubSpot instance with a Technical_Score__c custom field, you can apply a JSONata override exclusively to their integrated_account record without deploying any new code or affecting other customers.

For example, extracting a custom industry vertical field dynamically:

response.{
  "id": id.$string(),
  "name": properties.firstname & ' ' & properties.lastname,
  "industry": properties.custom_industry_vertical,
  "custom_fields": properties.$sift(function($v, $k) { $k ~> /^custom_/ })
}

This expression executes at runtime, mapping the custom data perfectly into your unified schema for that specific tenant. Custom fields work the same way on every plan—there is no enterprise gate.

Capability Merge Ampersand Truto
Custom field reads Yes (all plans, dashboard) Yes (native) Yes (all plans, JSONata)
Custom field writes Limited by plan Yes (native) Yes (all plans)
Programmatic field mapping Enterprise only Yes (amp.yaml) Yes (override hierarchy)
Per-tenant overrides Linked Account level Per-customer config Platform/Env/Account levels
Custom objects Passthrough only Native support Custom API + unified mappings

Data Privacy and Compliance: The Zero Retention Mandate

Storing your customers' data is a massive security liability. If you sell to healthcare, financial services, or any enterprise with a serious infosec team, the question "where does our data live?" will dominate every security review.

Merge is inherently a data processor and a data store. By caching your customers' HRIS, CRM, and ATS data on their servers, they become a critical link in your compliance chain. When Merge syncs an HRIS integration, it stores copies of employee records (names, SSNs, salary data) on their infrastructure. While encrypted at rest, you must justify to your enterprise buyers why this PII is sitting in a third-party vendor's database, and your data processing agreements must account for it.

Ampersand mitigates this by focusing on data delivery. It acts as the transport layer, writing the data directly into your infrastructure. You own the credentials and the data, but you also absorb the storage costs and the compliance burden of securing it at rest within your own boundaries.

Truto employs a strict zero data retention architecture. What does zero data retention mean for SaaS integrations? explains why this is critical for modern SaaS. Truto acts purely as an execution proxy. API responses pass through Truto's transformation layer and are returned to your application in real time. Truto holds the OAuth refresh tokens securely, but the actual payload data passes through memory and is immediately discarded. Truto never writes your customers' CRM contacts or accounting ledgers to disk. For security-conscious enterprise buyers, this eliminates an entire class of third-party compliance questions.

Rate Limits and Reliability at Scale

When your application connects to 50 different third-party APIs, you are suddenly subject to 50 different rate limiting strategies. Some APIs limit by the minute, some by the day. Salesforce, HubSpot, and Zoho all express their limits differently.

Many integration platforms claim to "magically handle" rate limits for you. This is a dangerous architectural anti-pattern.

Merge absorbs rate limits within its sync engine. Since it polls APIs on a schedule, it manages its own request pacing. You read from the cache, so you rarely hit limits directly. The downside is that heavily rate-limited upstream APIs degrade your sync frequency and data freshness.

Ampersand handles automated rate limiting as part of its managed infrastructure, handling retries and parsing error messages on your behalf.

Truto takes a radically transparent approach: it does NOT automatically retry, throttle, or apply backoff on rate limit errors.

Why? Because if middleware automatically retries a non-idempotent POST request (like creating an invoice or sending an email) that timed out, it risks duplicating data. Truto believes the caller should control retry behavior. If an upstream API returns an HTTP 429 Too Many Requests error, Truto passes that 429 directly back to your application.

However, parsing 50 different rate limit header formats is a nightmare. What Truto does do is normalize the rate limit information from upstream APIs into standardized response headers based on the IETF specification:

  • ratelimit-limit: The maximum number of requests allowed in the current window.
  • ratelimit-remaining: The number of requests remaining in the current window.
  • ratelimit-reset: The number of seconds until the rate limit window resets.

This gives your engineering team a single, consistent interface to build your own exponential backoff and circuit breaker logic. Best practices for handling API rate limits and retries outlines how to implement this safely.

// Example: Client-side rate limit handling with Truto
const response = await fetch('https://api.truto.one/unified/crm/contacts?integrated_account_id=abc', {
  headers: { 'Authorization': `Bearer ${TRUTO_API_KEY}` }
});
 
if (response.status === 429) {
  const resetInSeconds = parseInt(response.headers.get('ratelimit-reset') || '60', 10);
  console.warn(`Rate limited. Backing off for ${resetInSeconds} seconds.`);
  await sleep(resetInSeconds * 1000);
  // Safely retry the request here based on your app's specific business logic
}

Category Coverage and Integration Depth

Breadth versus depth is the oldest trade-off in the integration space, often forcing a choice between control and velocity.

Merge offers the broadest category coverage among traditional unified APIs, with support across HRIS, ATS, CRM, Accounting, Ticketing, and more. Their catalog of 200+ integrations is a strong selling point for teams needing massive checkbox coverage.

Ampersand focuses on depth over breadth. Depth-first platforms let you read and write to any custom object, even ones created yesterday that don't exist in any standardized schema. If your primary use case is a deep, bi-directional Salesforce integration, Ampersand is built for that.

Truto covers 27+ distinct API categories including CRM, HRIS, ATS, Accounting, Ticketing, Knowledge Base, LMS, and Marketing Automation. The full category breakdown shows how this stacks up against the competition. Crucially, Truto also offers a Proxy API for direct passthrough calls and a Custom API for accessing endpoints not yet covered by the unified model, ensuring you are never blocked by schema limitations.

Pricing Models: Per-Connection vs. Consumption vs. Platform

The most glaring difference between these platforms is how they penalize your growth. Pricing is where architectural decisions become financial ones.

Merge: The Per-Connection Tax

Merge uses a pricing model that scales linearly with your customer adoption. They offer a free tier for the first 3 production Linked Accounts. After that, standard plans charge roughly $650 per month for up to 10 linked accounts, and $65 for each additional account. Critically, each customer connection counts separately.

Let's model a mid-stage B2B SaaS with 200 customers, each connecting an average of 2 integrations (e.g., an HRIS and a CRM):

  • 200 customers x 2 connections = 400 linked accounts
  • First 10 included in $650/month base
  • 390 additional x $65 = $25,350/month
  • Total: ~$26,000/month ($312,000/year)

At 500 customers with 3 integrations each, you are well past $1M/year in unified API costs alone. This model actively punishes you for driving integration adoption and destroys unit economics for lower-ACV customers.

Ampersand: The Consumption Tax

Ampersand avoids the per-connection trap by charging based on data volume (per gigabyte processed). They provide a free Launch Tier with 2 GB of data delivery. An early-stage tenant with 10,000 CRM records moves roughly 0.10 GB per month, allowing you to host 15-20 customers for free.

This is highly cost-effective for small customers. However, if you land an enterprise customer who needs a historical backfill of a 50GB Salesforce instance, your infrastructure bill will spike unpredictably. Consumption pricing makes forecasting integration costs incredibly difficult for finance teams.

Truto: Developer-Friendly Platform Pricing

Truto decouples your integration costs from your customer acquisition success. Truto charges per integration (i.e., per third-party platform you connect to), not per customer connection.

You can have 10 connected accounts or 10,000 connected accounts—the platform does not penalize you for scale. Pricing is based on straightforward API usage tiers, allowing you to offer integrations to your entire user base without destroying your margins. Which unified API platform has the most developer-friendly pricing? breaks this down further.

Pricing Factor Merge Ampersand Truto
Model Per linked account ($65/ea) Per GB delivered Per integration (Platform)
Free tier 3 linked accounts 2 GB/month Contact sales
Scales with Customer count x integrations Data volume Number of third-party APIs
Predictability Linear with customer growth Variable with data volume Flat per provider
Enterprise custom fields Enterprise plan required Included Included

Strategic Wrap-Up: When to Choose Each Platform

There is no universal winner; the right choice depends on your specific constraints.

Choose Merge if:

  • Your application relies entirely on asynchronous, eventual-consistency data reads.
  • Your customer count is low enough that a $65-per-account tax doesn't destroy margins.
  • Your security requirements allow a third party to cache sensitive customer PII.

Choose Ampersand if:

  • You need deep, bi-directional integrations with specific systems of record (especially CRM).
  • Your engineering team wants to write and maintain declarative YAML manifests.
  • You prefer consumption-based billing and want to own the OAuth credentials directly.

Choose Truto if:

  • Real-time data consistency and strict zero data retention are hard enterprise requirements.
  • You need the ability to map enterprise custom fields dynamically without deploying code.
  • Your pricing model cannot tolerate per-connection fees that scale linearly with customer count.
  • You are building AI agents and require real-time tool calling and MCP server support. (How to safely give an AI agent access to third-party SaaS data covers this use case).

Making the Decision: What to Evaluate Next

If you are running this evaluation for your engineering team, here are the four steps you should take next:

  1. Model your pricing at 24-month projected scale. Do not look at today's customer count. Model where you will be in two years. Per-connection pricing that looks cheap at 50 accounts will become your largest infrastructure line item at 500.
  2. Get your infosec team involved early. If your compliance team will flag third-party data caching as a SOC 2 or HIPAA risk, that eliminates options before you write a single line of code. Read our guide on passing enterprise security reviews with API aggregators for specific questions to ask.
  3. Test with your most demanding customer's setup. Do not evaluate with a clean Salesforce sandbox. Use the customer who has 47 custom fields, three custom objects, and unique validation rules. That is the edge case that will break your abstraction layer.
  4. Ask about the exit path. What happens if you need to switch providers? Does the platform hold your customers' OAuth tokens hostage, forcing every user to re-authenticate?

The integration platform you choose will be one of the hardest pieces of infrastructure to rip out later. Take the time to test the edge cases, not just the happy path.

Frequently Asked Questions

What is the architectural difference between Merge, Ampersand, and Truto?
Merge uses a sync-and-cache architecture that polls APIs and stores data. Ampersand is a code-first managed ETL pipeline configured via YAML. Truto is a stateless, real-time proxy that uses JSONata to map data in memory without caching.
How do pricing models compare across these integration platforms?
Merge charges a per-linked-account fee (often $65+ per account) which scales linearly. Ampersand charges a consumption fee based on gigabytes of data processed. Truto uses platform pricing based on API calls and the number of integrations, avoiding per-customer penalties.
Does Truto store my customers' sensitive data?
No. Truto employs a strict zero data retention architecture. It acts as an execution proxy, holding OAuth tokens securely but passing the actual payload data through memory and immediately discarding it to simplify SOC 2 and HIPAA compliance.
How do unified APIs handle API rate limits?
Merge absorbs limits via its asynchronous polling engine. Truto takes a transparent approach, passing HTTP 429 errors directly back to the client while normalizing the headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) so developers can implement safe, custom retry logic.
Can I map custom Salesforce fields with a unified API?
Yes, but the approach varies. Merge often gates programmatic field mapping behind Enterprise tiers or requires passthrough endpoints. Ampersand requires manual YAML configuration. Truto handles custom fields natively on all plans using a 3-level JSONata override hierarchy without deploying code.

More from our Blog