ERP Integration: Middleware vs Direct API

“Should we use Boomi, build custom, or just use the native connector?”

This question comes up in almost every enterprise HubSpot implementation I lead. The client has an ERP — SAP, NetSuite, Microsoft Dynamics, Oracle, or something bespoke that was built in 2003 and understood by exactly one person who has since retired — and they need it talking to HubSpot.

The answer depends on factors that aren’t always obvious at the start. I’ve seen projects succeed with all three approaches, and I’ve seen projects fail with all three. The difference isn’t the technology — it’s whether the architecture matches the actual requirements.

Here’s the framework I use to make this decision. It’s saved me from making several expensive mistakes, and hopefully it’ll do the same for you.

The Integration Landscape in 2025

Before diving into the decision framework, let’s clarify the options:

Native Connectors (HubSpot Data Sync)

HubSpot offers built-in integrations for popular ERPs, including NetSuite, QuickBooks, and Xero. These provide:

• Two-way sync of standard objects (contacts, companies, deals)
• Pre-built field mappings
• Workflow actions (e.g., create NetSuite sales order from HubSpot deal)
• Managed by HubSpot — updates handled automatically

Limitation: Standard objects only. No custom object sync, limited transformation logic, and you’re dependent on HubSpot’s roadmap for new features.

iPaaS (Integration Platform as a Service)

Middleware platforms like Boomi, Workato, MuleSoft, and Celigo sit between systems:

• Visual workflow builders
• Pre-built connectors for hundreds of applications
• Data transformation and mapping
• Error handling and retry logic
• Monitoring and alerting

Considerations: Licensing costs scale with usage (connectors, tasks, data volume). Requires platform expertise. Adds another vendor to manage. Adds another vendor’s sales team to ignore calls from.

Custom Integration (Direct API)

Building integration logic in code using HubSpot and ERP APIs:

• Maximum flexibility
• No per-transaction licensing costs
• Full control over logic and timing
• Can be hosted anywhere (serverless, VPS, client infrastructure)

Considerations: Requires development resources. Ongoing maintenance burden. You own the error handling and monitoring.

The Decision Framework

I evaluate five factors when recommending an integration approach:

1. Data Complexity

Simple: Standard objects (contacts, companies, deals) with straightforward field mapping. Data flows in predictable patterns.

Complex: Custom objects, multi-level hierarchies (e.g., accounts → sites → contacts), calculated fields, conditional transformations, or data that requires enrichment during transfer.

2. Sync Direction and Timing

One-way batch: Data flows from ERP → HubSpot (or vice versa) on a schedule. Simplest to implement and debug.

Bi-directional batch: Both systems can update records, synced periodically. Requires conflict resolution logic.

Real-time (event-driven): Changes trigger immediate sync. Essential for time-sensitive workflows but harder to implement reliably.

Key insight: Real-time bi-directional sync is where projects get into trouble. Race conditions, duplicate records, and infinite loops are common. If you truly need this pattern, invest heavily in conflict resolution design. Then invest some more. Then accept it’ll still occasionally go wrong.

3. Volume and Frequency

iPaaS pricing consideration: Most iPaaS platforms charge by task or transaction. High-volume integrations can become expensive quickly. Model the costs before committing.

4. Internal Capabilities

Reality check: iPaaS platforms market themselves as “no-code,” but complex integrations require technical thinking. Someone needs to understand data models, API behaviours, and error handling — even if they’re not writing code. “No-code” means “code someone else wrote,” not “no complexity.”

5. Long-term Ownership

Who will maintain this integration in 2 years?

Common ERP Integration Patterns

Pattern 1: Sales Order Creation

Flow: Deal closed in HubSpot → Create sales order in ERP

This is the most common integration and often the simplest. HubSpot’s native NetSuite connector supports this directly.

Trigger: Deal stage = Closed Won
Action: Create NetSuite Sales Order
Mapping:
  - Deal name → Order reference
  - Company → Customer
  - Line items → Order lines
  - Deal amount → Order total

When to go beyond native:

• Custom approval workflows before order creation
• Split orders across multiple warehouses
• Complex product configuration or pricing rules
• Need to update HubSpot with order status changes

Pattern 2: Customer/Account Sync

Flow: Bi-directional sync of company and contact records

Conceptually simple, but conflict resolution is tricky. This is the integration that looks easy in diagrams and becomes surprisingly complicated in practice. Key questions:

• Which system is the source of truth for each field?
• What happens when both systems update the same record?
• How do you handle new records created in each system?

Recommended approach:

Field-level source of truth:
  - ERP owns: Payment terms, credit limit, account number
  - HubSpot owns: Lead source, marketing preferences, lifecycle stage
  - Shared (last-write-wins): Address, phone, email

Sync rules:
  - New ERP customer → Create HubSpot company (match on domain)
  - New HubSpot company (deal closed) → Create ERP customer
  - Updates → Sync owned fields to other system

Pattern 3: Quote-to-Cash

Flow: Full lifecycle from quote creation through payment receipt

This is where integration complexity explodes. You’re connecting at least five different processes, and every one of them has edge cases that someone will discover three weeks after go-live:

• HubSpot quotes → ERP quotes
• ERP quote approval → HubSpot deal stage
• HubSpot deal close → ERP sales order
• ERP invoice → HubSpot (custom object or timeline event)
• ERP payment → HubSpot (update deal properties)

My recommendation: Use iPaaS or custom integration. Native connectors rarely cover the full lifecycle.

Architecture sketch:

┌──────────────────────────────────────────────────────────────┐
│                         HubSpot                               │
│  Contacts  Companies  Deals  Quotes  [Invoices CO]           │
└──────────────────────────────────────────────────────────────┘
        │           │         │          │           ▲
        ▼           ▼         ▼          ▼           │
┌──────────────────────────────────────────────────────────────┐
│                    iPaaS / Custom Layer                       │
│  • Field mapping and transformation                          │
│  • Business logic (approvals, validations)                   │
│  • Error handling and retry                                  │
│  • Audit logging                                             │
└──────────────────────────────────────────────────────────────┘
        │           │         │          │           │
        ▼           ▼         ▼          ▼           │
┌──────────────────────────────────────────────────────────────┐
│                           ERP                                 │
│  Customers  Accounts  Orders  Quotes  Invoices  Payments     │
└──────────────────────────────────────────────────────────────┘

Pattern 4: Inventory Visibility

Flow: ERP inventory levels visible to sales in HubSpot

Sales teams need real-time (or near-real-time) visibility into stock levels. Options:

Option A: HubSpot Product properties

• Sync stock level to product properties
• Works for simple catalogues
• Limits: Product properties don’t support associations, reporting is basic

Option B: Custom object

• Create “Inventory” custom object with SKU, location, quantity
• Associate with Products or Companies
• Better for multi-warehouse, complex inventory models

Option C: External lookup (no sync)

• Use HubSpot CRM card or iframe to query ERP directly
• Always shows real-time data
• Doesn’t support HubSpot reporting or automation

Pattern 5: Customer 360 View

Flow: Aggregate ERP data for display in HubSpot

Sales and CS teams want to see ERP data (orders, invoices, support tickets, subscription status) without switching systems.

Options ranked by effort:

1. CRM Cards: Display ERP data via iframe or custom card. Least effort, real-time, but not searchable/reportable in HubSpot.

2. Timeline Events: Push ERP events to HubSpot contact/company timelines. Good for activity history, searchable, but not structured for reporting.

3. Custom Objects: Sync ERP data to HubSpot custom objects. Full HubSpot functionality, reportable, but requires ongoing sync maintenance.

iPaaS Platform Comparison (2025)

If you’re going the iPaaS route, here’s how the major platforms compare for HubSpot-ERP integration:

Pricing reality: Enterprise iPaaS contracts often start at $50,000+/year for meaningful usage. Budget accordingly. And maybe sit down before reading the quote.

When Native Connectors Win

Despite their limitations, native connectors are often the right choice when:

1. Standard use case: Contact/company sync, basic deal-to-order flow
2. Limited customisation needs: No custom objects, minimal field transformation
3. Budget constrained: iPaaS licensing costs aren’t justified
4. Speed to value: Need integration running in days, not weeks
5. HubSpot-managed: Team doesn’t want to own integration maintenance

Example: A 50-person company using NetSuite and HubSpot. They want deals to create NetSuite orders and invoices visible in HubSpot. The native connector covers 80% of requirements, and the remaining 20% can be handled with manual processes. Cost: ~£0 (included with HubSpot). Time to implement: 1-2 days.

When iPaaS Wins

Choose iPaaS when:

1. Multiple integrations: Connecting 5+ systems, not just HubSpot ↔ ERP
2. Complex transformations: Data needs significant manipulation between systems
3. Non-technical ownership: Business team needs to modify integration logic
4. Vendor support required: Need someone to call when things break
5. Audit and compliance: Require detailed logging of all data transfers

Example: A 500-person company with SAP, HubSpot, Salesforce, and a custom warehouse system. Data flows between all four systems with complex business rules. Workato provides a single platform to manage all integrations, with visual workflows that business analysts can modify. Cost: ~$100,000/year. Time to implement: 2-3 months.

When Custom Wins

Build custom when:

1. Bespoke ERP: No pre-built connector exists, or ERP has extensive customisations
2. Performance critical: High-volume, low-latency requirements
3. Cost sensitive: iPaaS licensing would exceed development + hosting costs
4. Full control needed: Specific requirements around hosting, security, or logic
5. Strong development team: Resources available for build and ongoing maintenance

Example: A company using a heavily customised Thor ERP that exposes data via proprietary APIs. No iPaaS connector exists. A custom integration hosted on AWS Lambda handles the sync, with logic tailored to their specific data model. Cost: ~£20,000 initial build + £5,000/year maintenance. Time to implement: 6-8 weeks.

Real-World Decision: Project Kaleidoscope

Recent project: Migrating a 225-user team from Microsoft Dynamics to HubSpot, with ongoing integration to their ERP.

Requirements:

• Bi-directional sync of accounts and contacts
• Deal-to-order flow with approval routing
• Invoice visibility in HubSpot
• Real-time inventory availability for sales
• Support for 150,000+ contact records

Decision process:

1. Native connector? Dynamics native sync exists but is limited. No support for custom objects (needed for invoices) or inventory lookup. Rejected.

2. Workato? Strong Dynamics connector, but client had no iPaaS experience. Licensing costs were ~$80,000/year for their volume. Considered but expensive.

3. Custom integration? Client had internal developers. Could build exactly what they needed. But ongoing maintenance burden was a concern. Possible.

4. Hybrid approach? Use native sync for standard objects. Custom integration for invoices and inventory. Selected.

Final architecture:

• HubSpot native sync: Contacts, companies, deals ↔ Dynamics
• Custom serverless functions: Invoice push to HubSpot custom object
• CRM card: Real-time inventory lookup (no sync)

Outcome: Fast implementation (3 weeks), manageable maintenance, costs within budget.

Key Takeaways

1. Start with requirements, not tools — Define what data flows where before selecting an approach
2. Native connectors are underrated — They cover 80% of use cases with near-zero effort
3. iPaaS isn’t magic — Complex integrations are complex regardless of the tool
4. Custom isn’t scary — With modern serverless and good documentation, it’s often the right choice
5. Hybrid approaches work — Mix native, iPaaS, and custom as requirements dictate
6. Budget for ongoing costs — iPaaS licensing, API calls, hosting, and maintenance all add up

The best integration architecture is the one that matches your specific requirements, team capabilities, and budget — not the one with the best marketing. I realise that’s less exciting than “always use [Platform X],” but it has the advantage of being true.

Working on an ERP integration project? I’d be happy to discuss architecture options — find me on LinkedIn.