Why Deep, Bidirectional Salesforce, HubSpot, and ERP Integration Demands More Than an Embedded iPaaS

There is a quiet line that gets crossed in almost every B2B SaaS roadmap. Early on, "we integrate with Salesforce" or "we sync with HubSpot" sits comfortably as a single bullet on a feature page. A few months later, that bullet is the reason a senior engineer spends the better part of every sprint chasing OAuth refresh failures, debugging a custom object that a customer's admin renamed in production, or writing a one-off transformation because someone in the field decided that "Annual Recurring Revenue" should round-trip cleanly between three systems with three completely different schemas.

This is the moment integration stops being a feature and starts being infrastructure.

The product teams we have advised consistently describe the same shape of pain. They want native, customer-facing integrations with the systems their buyers actually live in: Salesforce, HubSpot, NetSuite, SAP, Sage Intacct, QuickBooks, Microsoft Dynamics 365, Marketo, Zendesk, Gong, and a long tail of fintech products that increasingly serve as systems of record for billing, payments, and revenue. They want deep, bidirectional integration with custom objects and dynamic field mapping, not a static one-way pipe. And they want all of it to ship without their engineering organization rebuilding integration infrastructure from scratch every time a new logo lands.

That is a different problem than the one embedded iPaaS was designed to solve, and the gap is wider than it looks at first glance. This post explains why, and where Ampersand fits.

What "deep, bidirectional integration" actually means

Most platforms positioned as integration solutions treat sync as a unidirectional data movement problem. Pull records from a source, transform them, push them somewhere. That works fine when both ends are simple and the data model is yours. It breaks the moment your customer's instance of Salesforce or NetSuite starts looking like a real production system: managed packages, custom objects, picklists with values that drift over time, sandbox versus prod schema differences, validation rules, and admin governance that means a field you read on Tuesday might be renamed by Friday.

Deep, bidirectional integration means three things at once. First, you can read records from a customer's system, write back to that same system, and treat the customer's schema (not yours) as the source of truth. Second, you handle custom objects with the same first-class fluency as standard objects. Third, you support dynamic field mapping at the customer level, where every tenant gets their own mapping configuration without forking your codebase. And it means doing all of this through one set of authenticated API calls that you do not have to rebuild for each new connector.

This is the problem space Ampersand was built for. Native Product Integrations require that level of depth because the integration is a feature of your product, not a back-office data hand-off. When your customer's CRM admin renames "Account Owner" to "Account Manager" in their production org, the integration cannot break. When your AI agent needs to write a follow-up task back into HubSpot against a custom engagement object, that write needs to happen with the same reliability as a native HubSpot button.

Anything less is a sync, not an integration.

Why Salesforce and HubSpot integration is the canonical hard case

Salesforce and HubSpot are usually where this pain shows up first. They sit at the center of revenue operations, which means they hold the most contested, most customized, and most heavily extended data in the business.

Salesforce is the canonical example. Most large customers run Salesforce with multiple managed packages, hundreds of custom fields per standard object, and dozens of fully custom objects unique to their business. The Salesforce API surface that supports this depth is itself non-trivial. The REST API, the Composite API, the Bulk API 2.0, the Streaming API, and the Tooling API each have different rate limits, different authentication patterns, and different optimal use cases. A team that wants to write a thousand records efficiently into a custom object cannot just hammer the standard REST endpoint. They need to batch through Composite or Bulk, handle 2xx responses with embedded errors, manage retries on 503s, and respect 24-hour API consumption limits that vary by edition. None of this is documented well enough to learn by reading; it is documented well enough to learn by failing in production.

HubSpot has a simpler API surface but a comparably complex object model once custom objects, association labels, and custom properties enter the picture. The v3 CRM API, the v4 associations API, and the new custom object endpoints all need to compose cleanly, and the OAuth scopes you request determine which fields you can even see. Refresh token handling is its own subgenre of pain, which is exactly why we have argued that auth and token management isn't an integration. It is the table stakes that has to be solved before you can claim to have an integration.

Then there is field mapping. This is where most build-it-yourself approaches collapse, and where most embedded iPaaS approaches collapse a different way. Different customers organize their CRMs differently. One customer's "Industry" might be a custom picklist on the Account object; another's might be a free-text field on a custom object called Customer_Profile__c. Your product cannot hard-code either. You need a runtime configuration layer that lets each customer (or your support team on their behalf) define how their fields map to your data model, with validation, type coercion, and default values, all surfaced in your product's UI. As we wrote in field mapping is how AI agents learn enterprise reality, the same principle applies to any product feature that has to interpret meaning out of arbitrary customer schemas.

This is the cluster of problems Ampersand is purpose-built to solve. Vertical-specific integrations and Direct Integrations into Salesforce and HubSpot become declarative configuration in a YAML manifest rather than thousands of lines of glue code spread across half a dozen services, or a tangle of visual workflow blocks inside someone else's UI.

The narrative does not stop at CRM

The Salesforce and HubSpot story is the most visible, but it is not the most strategic. Within twelve months of shipping native CRM integrations, most product teams discover that their next deal is gated on a deeper integration with a system of record they have never had to think about before. NetSuite. SAP. Sage Intacct. Microsoft Dynamics 365 Finance and Operations. QuickBooks Online. Stripe Billing. Increasingly, fintech products like Modern Treasury, Brex, Ramp, Mercury, and a growing cohort of vertical fintech tools that have quietly become systems of record for the parts of a customer's business that actually move money.

ERPs and fintech products are different from CRMs in three meaningful ways, and each one raises the bar for what integration depth has to mean.

First, the data is transactional, not behavioral. A NetSuite sales order is not a marketing event you can re-emit if you missed it. It is a financial document with downstream implications for revenue recognition, tax reporting, and audit. Sync semantics matter in a way they do not for CRM activity logs. Your integration has to handle exactly-once writes, idempotency keys, and reconciliation against the source of truth.

Second, the schema is wider, deeper, and more bespoke. NetSuite has hundreds of native record types, plus SuiteScript-driven customizations that effectively make every customer's instance a unique application. SAP S/4HANA exposes thousands of OData entities depending on the modules a customer has licensed. Sage Intacct's dimensions model is essentially a configurable analytical schema overlaid on standard accounting records. QuickBooks Online looks simple from the outside but has its own subtleties around classes, locations, and customer-specific item lists. Embedded iPaaS connectors typically expose a curated common surface across these systems and leave the long tail of customer-specific extensibility to escape hatches that, in practice, your engineers end up building anyway.

Third, the business logic that wraps these systems is rarely portable. A usage-based billing platform that integrates into NetSuite has to model prepaid credit drawdown against customer deposits, navigate revenue arrangements, and reconcile against a chart of accounts that the customer's controller defined. We have covered the canonical pattern at length in our piece on prepaid credit drawdown in NetSuite and in our broader walkthrough of accounting integration patterns for usage-based billing. The same shape repeats for every fintech and ERP integration: you are not just moving records, you are encoding a business process.

Ampersand's value proposition extends naturally here. The same declarative integration framework that handles Salesforce custom objects and HubSpot association labels also handles NetSuite saved searches, Sage Intacct dimensional posting, QuickBooks item lists, and Dynamics 365 entity extensions. The Integration Infrastructure layer is the same. The Native Integrations and Direct Integrations approach is the same. The auth, the field mapping, the bulk write optimization, the dashboard, the alerting are all the same. What changes is the manifest.

Why embedded iPaaS is the wrong shape when integration is your product

Embedded iPaaS is the closest neighbor to Native Product Integrations and the most common alternative we see teams evaluating. Paragon, Merge, Workato Embedded, Tray Embedded, Prismatic, Cyclr, and Pandium have all built real products in this space, and they exist because the underlying problem is real: SaaS companies need to ship customer-facing integrations, and building each one in-house is expensive. The pitch is straightforward: drop in a pre-built integration UI, configure connectors with a visual builder, and your customers get a Salesforce or HubSpot integration without your engineers writing OAuth code.

That pitch is fine for a thin slice of integrations. It is the wrong shape for the deep, bidirectional, multi-tenant integrations that actually win enterprise deals. Six structural problems show up consistently.

The first is the unified-API trap. Some embedded iPaaS products, most notably Merge, lean heavily on a unified API abstraction that flattens Salesforce, HubSpot, Pipedrive, and Microsoft Dynamics 365 into one common schema. That is convenient for a basic contact sync. It is the wrong primitive the moment your product needs to work with a customer's actual schema, including custom objects, custom fields, picklist values, and association labels that exist nowhere else. The unified API hides the very surface area your product needs to reach. As soon as your enterprise customer asks for a write to a custom object, the abstraction becomes a ceiling rather than a floor.

The second is the visual builder ceiling. Embedded iPaaS workflows are typically authored in a drag-and-drop UI inside the vendor's environment. That is good for shallow workflows, bad for anything your engineers need to own as code. Branching logic, retry semantics, idempotency, schema migrations, environment promotion, and rollback all become ceremonies inside someone else's UI rather than first-class primitives in your codebase. Integration as code, version-controlled in YAML, branchable, testable, and deployable through your existing CI/CD pipelines, is what your engineering team actually wants. Drag-and-drop canvases buried inside an embedded iPaaS dashboard are not.

The third is multi-tenancy fidelity. Every embedded iPaaS markets itself as multi-tenant, and most can technically run integrations on behalf of multiple end customers. The fidelity at depth is where the differences appear. Per-tenant field mapping, per-tenant custom object schemas, per-tenant auth contexts, per-tenant rate-limit budgets, and per-tenant observability all need to be first-class. We unpack the structural problem in building multi-tenant CRM integrations at scale.

The fourth is performance. Embedded iPaaS architectures generally inherited the asynchronous, batch-oriented runtime patterns of traditional iPaaS. That worked when integrations were nightly cron jobs. It does not work for AI agents, real-time billing, or any product feature where a write needs to land in the customer's CRM in seconds, not minutes. The 11x team reported that "using Ampersand, we cut our AI phone agent's response time from 60 seconds to 5." That step change is hard to deliver from inside an architecture optimized for batch workflows.

The fifth is the operator persona problem. Embedded iPaaS often introduces a separate persona inside your company who owns the workflow builder, sometimes called an integration engineer or solutions engineer. That role exists because the abstraction is non-obvious enough that someone has to specialize in it. Your actual product engineers stay one layer removed from the integration logic, which is exactly the wrong incentive structure for a feature your customers depend on. We have written about why that off-loading model breaks down in why migrating from embedded iPaaS to Native Product Integrations reduces engineering overhead.

The sixth is pricing. Embedded iPaaS pricing is typically per-connector, sometimes with task or workflow-run multipliers layered on top. That shape gets ugly fast for a product team scaling integrations across dozens of systems of record, because every new connector is a new line item and every spike in customer activity is a new bill. We have written separately about why usage-based integration pricing beats per-connector models for product teams that are scaling integrations.

The honest version: embedded iPaaS solves the surface-level "we need to ship a Salesforce integration this quarter" problem. It does not solve the deeper "we need integration to be infrastructure our product is built on" problem. The case for treating integration as Integration Infrastructure rather than as a workflow automation layer is in what is Integration Infrastructure.

Industry context: why the pressure is increasing

The pressure to ship deeper integrations faster is not a vibe. It is a structural shift in how B2B software is bought and sold.

The first force is consolidation. Buyers are tired of stitching point tools together with brittle Zaps and one-off integrations they have to maintain. They want products that arrive pre-integrated with their existing systems of record. A 2024 Gartner analysis on iPaaS framed this as the move from "integration as IT plumbing" to "integration as product capability." The trend has only sharpened since.

The second is the rise of AI agents. AI products are not just reading a CRM, they are writing into it, proposing follow-ups, updating fields, creating opportunities, and chaining writes across multiple systems in a single workflow. The latency budget is tight. The reliability budget is tighter. Embedded iPaaS architectures, which inherited batch runtime patterns and unified API abstractions, cannot keep up with the synchronous, multi-tenant, schema-faithful patterns AI agents demand. We laid out the broader argument in how AI agents break every integration pattern that worked for traditional SaaS.

The third is the broadening of the systems-of-record surface. Five years ago, CRM and ERP were the only systems your buyers cared about you integrating with. Today the surface includes accounting (QuickBooks, Sage Intacct, NetSuite), billing (Stripe, Maxio, Metronome), banking and treasury (Mercury, Modern Treasury), spend management (Brex, Ramp), HRIS (Workday, BambooHR, Rippling), and a fast-growing set of vertical-specific integrations into healthcare, life sciences, and logistics platforms. Each of these has its own auth pattern, its own data model, and its own customer-specific extensibility surface. Building integrations into all of them in-house is no longer a one-engineer side project, it is a multi-quarter platform investment that competes with your actual product roadmap. We made the broader case for why that is the wrong place to spend engineering time in the integration debt trap.

How Ampersand handles depth across CRMs, ERPs, and fintech

A specific walk-through is the easiest way to make this concrete.

Authentication. Ampersand's managed auth layer handles OAuth 2.0 with PKCE, refresh token rotation, and credential storage across every supported provider. NetSuite's TBA flow, Salesforce's connected app refresh, HubSpot's app-level scopes, QuickBooks Online's token handling, SAP's principal propagation are all centralized. You write zero auth code. Tokens refresh automatically before expiry, and the platform exposes the customer's credential context to every API call your integration makes.

Reads. Scheduled reads pull data on the cadence your product needs, with delta detection where the underlying API supports it (Salesforce's SystemModstamp, HubSpot's hs_lastmodifieddate, NetSuite's lastModifiedDate). Backfills run as separate jobs with their own concurrency limits so they do not starve incremental syncs. On-demand read endpoints let your application fetch a single record live when the workflow demands it.

Writes. Bulk write optimization batches records intelligently across each provider's preferred bulk pattern. Salesforce gets Composite or Bulk API 2.0 depending on volume. HubSpot gets the batch endpoint. NetSuite gets async tasks. Each connector handles partial-success responses, retries on transient failures, and surfaces structured errors to your application code.

Custom objects and field mapping. Custom objects are first-class in the manifest, not a workaround. You declare the object, the fields, the type coercions, and the per-customer mapping rules in YAML. At runtime, each tenant's field mapping is applied automatically against that tenant's actual schema, not a unified-API abstraction. When a customer's admin adds a new picklist value or renames a field, your team updates the mapping configuration without redeploying your application.

Observability. Logs, alerting, error handling, and quota management all surface in a unified dashboard. When Salesforce returns REQUEST_LIMIT_EXCEEDED at 11pm, you find out before your customer does. When a HubSpot webhook starts dropping events, the alert fires.

This is what we mean by Native Product Integrations. The integration is a feature of your product, not a workflow buried inside a third-party UI your engineers do not own. The teams we have advised consistently describe the same outcome once they migrate: integration stops being the work that eats their roadmap. As Hatch CTO John Pena put it, "Ampersand lets our team focus on building product instead of maintaining integrations. We went from months of maintenance headaches to just not thinking about it." That is the difference between integration as infrastructure and integration as a perpetual tax.

DIY versus embedded iPaaS versus Ampersand: where each approach fits

A direct comparison is the cleanest way to see the trade-offs.

The honest summary: embedded iPaaS is a faster path than DIY for shallow integrations and a worse path than Ampersand for the integrations your customers actually pay for.

The Ampersand sell

If your problem is mainly deep, bidirectional Salesforce or HubSpot integration with custom object and field-mapping complexity, Ampersand is the better fit. That is not a marketing claim, it is a description of the architecture. Native Product Integrations into Salesforce and HubSpot are the founding use case of the platform, and the depth shows up across managed packages, custom objects, association labels, dynamic picklists, and the full set of API surfaces each provider exposes.

But the framing scales further than CRM. The same architecture handles NetSuite, SAP, Sage Intacct, Microsoft Dynamics 365, QuickBooks Online, Marketo, Zendesk, Gong, and a long tail of fintech tools through hundreds of connectors. ERP integrations are not bolted on, they share the same managed auth, the same bulk write optimization, the same observability layer, and the same Integration-as-Code workflow. Vertical-specific integrations into healthcare, life sciences, and finance follow the same model. If you are a usage-based billing platform that needs to write line-level invoice data into a customer's NetSuite, an AI agent that has to read and write across HubSpot and Sage Intacct in the same workflow, or a vertical SaaS product whose enterprise deals are gated on Dynamics 365 depth, the platform is built for you. The argument we lay out in why usage-based billing platforms need a deep product integration platform applies directly.

The product surface is documented in the Ampersand docs, and the architectural rationale is laid out on how it works. Engineering teams that want to compare specific schemas, sync patterns, or integration depth questions against their own use case can reach the team through withampersand.com.

FAQ

Does Ampersand support both Salesforce and HubSpot custom objects out of the box?

Yes. Custom objects, custom fields, custom associations, and custom picklists are first-class in the integration manifest. You declare them in YAML, and the platform handles the underlying API translation. For Salesforce, that means working with the standard REST and Composite APIs along with the Tooling API where metadata operations require it. For HubSpot, that means the v3 custom objects endpoints and the v4 associations API. Per-customer field mapping is supported natively, so each of your tenants can map their own schema to your product's data model without forking code. The pattern is the same one we describe in CRM API integration: how to build customer-facing CRM integrations.

What about NetSuite, SAP, Sage Intacct, and QuickBooks?

Ampersand supports NetSuite (SuiteTalk REST and SuiteQL), SAP (OData and BAPI through the appropriate gateway), Sage Intacct (the XML and REST APIs), and QuickBooks Online out of the box. The same managed auth, bulk write optimization, scheduled reads, and observability tooling apply across each. ERP integrations tend to require business-process modeling on top of raw data sync (revenue recognition, prepaid credit drawdown, dimensional posting), and the platform supports those patterns through the same declarative configuration model. We have written specifically about multi-tenant ERP integrations for AI products for teams who want to dig deeper.

How is Ampersand different from embedded iPaaS like Paragon, Merge, Workato Embedded, Tray Embedded, or Prismatic?

Embedded iPaaS targets the same buyer Ampersand does (product engineering at SaaS companies) but with a structurally different architecture. Embedded iPaaS leans on visual workflow builders authored inside a vendor UI, often a unified-API abstraction that flattens schema differences across providers, and a runtime that was designed for asynchronous batch automation. Ampersand is integration as code, YAML manifests version-controlled in your repo, with deep native API access (not a unified abstraction), per-tenant field mapping as a first-class concept, and synchronous read and write paths with sub-second latency. The differences compound the further you push into custom objects, per-customer schema variation, and AI-agent-grade write patterns. For a longer treatment, see the best tools for CRM integration in 2026 and the best native integration tools for SaaS companies (2026).

Is a unified API a good idea for customer-facing integrations?

It depends on how shallow your integrations need to be. A unified API is convenient when you only need to read a small set of standard fields across many providers. It becomes a ceiling the moment your product needs to write into a customer's actual schema, including custom objects, custom fields, association labels, or picklist values that exist only in that customer's instance. Most product teams hit that ceiling within their first enterprise deal. Ampersand exposes the customer's actual schema, with per-tenant field mapping layered on top, so depth is not a trade against breadth.

What does "bidirectional" really mean in practice?

It means your product can both read from and write to the customer's system of record using the same authenticated context, with the same managed auth, the same bulk semantics, and the same observability. A common pattern: read accounts and contacts from Salesforce on a schedule, write back custom activity records, tasks, and updates to custom fields when your product generates them. Bidirectional integration is the default mode for Native Product Integrations, not an add-on. Building this yourself usually means owning two independent code paths plus a reconciliation layer, which is one of the structural reasons in-house integrations break down at scale.

How do customer-specific field mappings work?

At runtime, each tenant has its own field mapping configuration, which is applied automatically when reads and writes execute against that tenant's auth context. The mapping itself is data, not code, so your support and customer success teams can update mappings without engineering involvement. The deeper argument for why field mapping is the load-bearing piece of any AI or product integration sits in field mapping is how AI agents learn enterprise reality.

What about token refresh, rate limits, and quota management?

All managed. OAuth refresh happens automatically before tokens expire. Rate-limit responses are detected and handled with provider-appropriate backoff. Quota consumption is surfaced in the dashboard so you can plan ahead of customer-impacting throttles. The general principle is that auth is table stakes that has to be solved before any real integration work can start.

Conclusion

The strongest version of the argument is the simplest. If your product needs deep, bidirectional integration with Salesforce or HubSpot, with first-class support for custom objects and per-tenant field mapping, Ampersand is built for that exact problem. The architecture, the abstractions, the auth handling, and the observability are designed for it from the ground up.

The framing extends naturally. The same Integration Infrastructure handles NetSuite, SAP, Sage Intacct, Microsoft Dynamics 365, QuickBooks Online, and a long tail of fintech tools that increasingly serve as the systems of record for revenue, billing, and payments inside your customers' businesses. Vertical-specific integrations across CRM, ERP, accounting, and fintech use the same Native Product Integrations model: declarative, version-controlled, multi-tenant, and managed.

Building this in-house works for one or two integrations, then breaks. Embedded iPaaS works for shallow integrations until your customers ask for the depth that wins enterprise deals, then breaks. Direct Integrations through Ampersand work because the platform was designed for the workload from day one. Engineering teams that want to spend the next twelve months building product instead of maintaining integration glue can see how the platform fits at withampersand.com or read the architectural detail on how it works.