Ampersand vs Unified APIs
Ampersand’s integration infrastructure is built for the agentic era. Unified APIs are a good fit when customer data is very similar and only requires a thin integration. Ampersand is uniquely suited to handle the complexity of highly customized systems of record like CRMs and ERPs.
Unified API providers
Merge, Apideck, Unified.to, Rutter, and Codat are some of the unified API providers product teams evaluate. This page broadly compares the unified API approach with Ampersand’s integration infrastructure approach. Features and capabilities will vary from vendor to vendor.
When teams outgrow their unified API
Unified APIs are a good fit when your customers’ systems are all relatively similar. As companies move up market, build agentic capabilities, or start integrating with legacy systems of record, they often find that the unified API approach no longer offers the customization and depth their customers require.
01 Limitations with the common data model
The premise of a unified API is that you build one common data model used by all of your customers. In theory, this makes it simple to onboard new customers to the integration as well as build integrations for multiple CRM providers. In reality, systems of record tend to be highly customized and complex. By the time you’re selling into the enterprise, your team is faced with decades of custom fields, objects, and workflows. There is no common data model.
Ampersand starts from a very different assumption: that every system of record in the enterprise will be highly customized. Ampersand gives you access to everything in the system, including custom objects and fields. Your customers are then empowered to map their own objects and fields to your data model. This deep integration approach is built on a fundamentally different point of view than unified APIs.
And if you want a unified model, you can still have one. With Ampersand, you can define your own unified API: map Salesforce accounts and HubSpot companies to the same object, with the field names you choose, and launch every CRM from a single configuration. You define the schema, instead of being locked into a vendor’s.
When companies encounter this pain
- Each customer has custom objects and fields. Enterprise customers track leads, deals, and receivables in custom objects. In a common data model approach, every one of these customizations will require your engineers to write custom code.
- Each system of record has unique concepts. The promise of a unified API is that you’re not just building a HubSpot integration, you can rapidly ship integrations with all CRM vendors. The challenging reality is that these vendors have divergent concepts. HubSpot has Forms, Salesforce doesn’t. A unified CRM model can only be built to cover concepts that exist in all platforms.
- Each system of record is a suite, not a single product. There is NetSuite and then there is NetSuite SuiteTax; there is Workday HR and Workday billing. There is Salesforce and then there is Salesforce CPQ. Many companies choose a unified API provider only to learn later that it doesn’t actually integrate with the full suite of products they need access to.
Fullcast grew through acquisitions, and each company it bought came with its own way of integrating with Salesforce, Gmail and Calendar. When the team built its AI-native revenue intelligence product, it went all in on Ampersand instead.
“We needed integrations built for our product, with control over the data model. Ampersand’s configuration-driven approach enables us to define the schema ourselves.”
02 Security teams push back on cached data
Many unified APIs, including the most widely used, sync your customer’s CRM or ERP, store a copy of that data, then answer API calls from that copy. For your customer, this means an additional third party now holds their data.
Ampersand takes a different approach, acting only as the transport layer. Ampersand reads data, then delivers it directly to the destination. When your agent writes data, Ampersand makes the write. This makes it easier for your company to pass customer security reviews, and also ensures data is fresher.
When companies encounter this pain
- Security review. Enterprise security and legal teams will want to know who is holding their data. A third party holding a copy of their data can slow or derail a deal.
- Regulated data. This risk is even greater in banking, healthcare, or in the EU.
- Stale or one-way data. Scheduled syncs leave your product and agents working with data that is minutes or hours old. While this lag time might be acceptable in the SaaS era, it is rarely acceptable for companies building agentic capabilities.
03 Pricing that eats your margins
Unified APIs usually charge per linked account: every connector for every customer will increase your bill. Ten customers on HubSpot and Gong means you’re paying for twenty connected accounts.
Ampersand’s pricing is based on how your product uses its integrations, not on how many customers or connectors you have. Adding the next integration or the next customer doesn’t add another connected account to your bill.
When companies encounter this pain
- Adding long-tail integrations. Enterprise customers connect many systems (Salesforce, Jira, Zendesk, Marketo), and each of these connections will eat into your margins.
- Juggling several integration approaches. To protect margins, teams build their core integrations in-house and send the long tail to a unified API. Every approach is another code repository to maintain and another place where integrations can fail.
Core differences between unified APIs and integration infrastructure
| Dimension | Unified API | Ampersand |
|---|---|---|
| Data Model | The vendor’s common model for each category | Your own schema, defined with object and field mappings, or each system’s real field names |
| Custom Objects & Fields | Outside the common model; custom code per customer | Read and write any standard or custom object or field, and watch for schema changes |
| System-Specific Features | Limited to what the common model covers | The full API, including proxy calls to any endpoint |
| Per-Customer Configuration | Reconfigured by hand for each customer | Customers map their own objects and fields in an embeddable UI |
| Customer Data | Often a synced copy, served from cache | Passed through; only tokens and settings stored long term |
| Real-Time Events | Scheduled syncs; varies by provider | Subscribe actions built on provider webhooks and change data capture |
| Write-Back | Varies by integration and object | Two-way, reverse-mapped to each customer’s own fields |
| Pricing | Per linked account or connection | Based on product usage, not connections (see pricing) |
| Token Ownership | Varies by vendor | Import and export your customers’ OAuth tokens |
| Configuration | API, SDK and dashboard | Declarative amp.yaml in your Git repo |
| Compliance | Varies by vendor | SOC 2 Type II, ISO 27001, GDPR, CCPA, HIPAA |
Why engineering leaders choose Ampersand
-
Systems of record require domain expertise
Enterprise agents depend on systems of record like CRMs and ERPs to understand context and take action. These systems are complex and highly customized, and a common data model flattens the custom objects and fields that make each customer’s instance unique. With Ampersand, your engineering team can ship deep, bi-directional integrations that work with every customer’s own objects and fields.
-
Integrations should be managed as code
Ampersand is built for developers. No black-box unified API sitting between your product and the provider. You define the objects, fields, and actions in your Git repo, with full control over your data model, great documentation, and the workflows your team already knows and loves.
-
Integration maintenance eats into time building the core product
Writing the initial API call takes an afternoon. Keeping track of rate limits, API changes, and schema drift across hundreds of customer accounts takes a dedicated team. Ampersand takes on that burden without forcing your integrations into a lowest-common-denominator model.
When to use a unified API vs Ampersand
Use a unified API when
- Your customers’ data is simple and standard and the systems you connect to are rarely customized.
Use Ampersand when
- You sell to mid-market and enterprise customers with customized CRMs and ERPs, and your agentic product needs fresh, bi-directional data.
Frequently Asked Questions about unified APIs vs Ampersand
-
How is Ampersand different from a unified API?
A unified API gives you one common data model per category, such as CRM or ERP, so you can turn on many integrations at once. The trade-off is depth. You adopt the vendor’s model, so your customers’ custom objects, custom fields, and features unique to one system need extra code. Ampersand gives you full access to every object and field and lets you normalize data across systems with mappings that you define. In addition, Ampersand serves only as a transport layer, so it doesn’t keep a copy of your customers’ data.
-
Does Ampersand store my customers’ data?
Not long term. Ampersand is a transport layer: when it reads data, it delivers it to your destination (a webhook, AWS Kinesis or S3) right away, and when you write data, it makes the write. It stores your customers’ encrypted access tokens and their integration settings, such as field mappings. Data is held only long enough to replay a failed delivery if needed.
-
Can I still get one unified model across systems?
Yes! The difference is that you will define it (rather than the unified API provider). User-defined mappings will allow each of your customers to pick the custom fields they actually use.
-
How does pricing work as we add customers and integrations?
Pricing is based on product usage, not the number of connectors or customers. See pricing.
-
What if you don’t support the integration or endpoint I need?
Every connector lets you read and write any standard or custom object, and proxy actions give you authenticated access to any endpoint in the provider’s API. If Ampersand doesn’t have a connector yet, the team can build one, typically in about two weeks, given API access and ideally a sandbox to test against.
Keep reading
Further comparisons
-
Compare
Embedded iPaaS
Ampersand’s integration infrastructure is built for the agentic era. Embedded iPaaS is focused on workflow automation and orchestration. This approach worked for the SaaS era, but underperforms in AI-native products.
-
Compare
ETL tools
ETL tools, including reverse ETL, are designed to move your own data into and out of your data warehouse. This is a different use case than Ampersand. Ampersand is integration infrastructure for enterprise products, allowing each of your customers to connect their system of record to your product so agents can read and write to that data.
-
Compare
Build vs buy for integrations: the real cost
The first version is the easy part. Here’s what building integrations actually cost once maintenance, opportunity cost, and scale enter the picture.
Switching from a unified API? Start with one integration.
Ampersand can import your customers’ existing OAuth tokens, so they don’t have to reconnect when your current provider supports export. Move one integration at a time, at your own pace.