Custom vs Native HubSpot Integrations: When the Marketplace App Is Not Enough
HubSpot’s marketplace is full of apps that promise “Amazon,” “Redshift,” “Teamwork,” “PayPal,” or “accounting” in one click. Some of them are good. Many of them are a field mapper with a logo.
The search query is usually custom vs native HubSpot integrations. The real question is: will this app own the exception cases, or will your team still be the integration?
I decide that on every HubSpot integration project before anyone writes code.
Native is the default, not the enemy
Use a native HubSpot integration when all of these are true:
- Objects in HubSpot match objects in the other system (contact, company, deal, ticket)
- Field names are boring
- A missed sync is annoying, not a revenue event
- You can name one owner who will notice when the app’s token expires
That covers a lot of Shopify, Mailchimp-class, and simple Slack notifications. Buy the app. Move on.
Custom starts at the exceptions
Build custom HubSpot integrations when any of these show up:
- Custom objects the app does not know about
- Two-way sync with conflict rules (who wins if HubSpot and the warehouse disagree)
- ERP or finance systems (Business Central, SAP S/4HANA, accounting ledgers with tax and dimensions)
- Commerce that is not a standard Shopify order (Amazon seller data, partial refunds, kits)
- Data platforms (Redshift, PostgreSQL, AWS jobs) where HubSpot is a source, not a BI tool
- Project tools (Teamwork, Smartsheet) that need templates driven by deal properties
- A portal that has to show live CRM state, not a nightly CSV
Those are the queries Google already dumps on the HubSpot service page: Amazon, AWS, Redshift, PayPal, Cyfe, 3CX, Make. Most of them do not deserve their own URL. They deserve a decision: native app, Make scenario, or custom API.
A simple decision table
| Signal | Native app | Make / Integromat | Custom API |
|---|---|---|---|
| Two standard objects, few fields | Yes | Maybe | No |
| You are still discovering the process | Yes / wait | Good for a spike | Too early |
| Custom objects or ERP | Rarely | Gets messy | Yes |
| Volume or 2 a.m. failures cost money | Risky | Risky | Yes |
| You need retries, alerts, docs | Unlikely | DIY | Yes |
Make is not “custom.” It is a hosted script. Fine for a test. Fragile as a finance pipeline.
How I keep custom from becoming a science project
- One vertical slice: one object, one direction, one alert.
- Match keys stored on both sides so we do not duplicate customers.
- HubSpot stays the CRM. It does not become your ERP, warehouse, or project manager.
- Your team gets a runbook. If only I understand the sync, I failed.
Examples of that slice in production-shaped work: HubSpot + Business Central and HubSpot + Teamwork.
What to do this week
List the HubSpot objects that matter and the other system that is supposed to agree with them. If a native app maps those objects, install it in a sandbox. If you already did and staff still retype, book a free call. Bring the two records that should have matched and did not. That is the whole brief.
