Custom APIs and Middleware for HubSpot: When Custom Development Pays Off
When do standard HubSpot integrations suffice, and when do you need a custom interface or middleware? Concrete signals, what middleware actually does, and what to look for in a partner.
Custom APIs and Middleware for HubSpot: When Custom Development Pays Off
In almost every first conversation I hear some version of this question: "We want to connect HubSpot to system X. Is a ready-made integration enough, or do we need to have it built?" Behind it sits a second, often unspoken question: who do you even turn to for that?
Both questions have answers, but not blanket ones. Whether you need a custom interface depends on what has to happen between the systems. And the right partner depends on how deep the custom development actually goes. Here I try to sort out both, the way I work through it on projects.
What you can already cover with standard tools
Before anyone considers custom development, it's worth looking at what works with no code or very little. HubSpot has a marketplace of ready-made integrations for the common tools: Mailchimp, Slack, Gmail, plenty of accounting and calendar apps. If your requirement is "contacts from tool A should land in HubSpot" and both sides offer a ready connection, you don't need development. You need an hour to set it up.
The next step up is automation platforms like n8n, Make or Zapier. With those you connect HubSpot to hundreds of other services without programming an API connection yourself. A form fills a contact, a new deal triggers a Slack message, a nightly run reconciles two lists. For a large share of the requirements that come up day to day, that's the right answer. Which of these tools fits when, I covered in more detail in my comparison of n8n, Zapier and Make.
My point: custom development isn't the default route, it's the route for the cases where the standard routes no longer hold. Anyone who starts with a complex custom build when a ready-made integration would do is paying for complexity they don't need.
The signals that tell you you need a custom interface
There are a few recurring patterns where I'll say fairly quickly in a conversation: here you won't get around a custom interface.
The first is logic no ready connector can express. A real example: before an order from the ERP becomes a deal in HubSpot, several line items have to be summed, discounts accounted for, and a status derived from two fields. A standard connector doesn't know these rules. It can map field to field, but it can't calculate and decide.
The second is a data source with no ready connection. Many industry systems, legacy systems or home-grown databases have no entry in the HubSpot marketplace and no connector on the automation platforms. When the only door is a raw API or a database connection, someone writes the code that walks through that door.
The third is data volume and stability. An occasional sync of a few contacts is uncritical. But as soon as tens of thousands of records move regularly, topics that stay invisible in a ready connector start to matter: the HubSpot API's rate limits, the behaviour when a run breaks off mid-way, avoiding duplicate records. For more on what's actually possible over the API in the HubSpot CRM and where the limits sit, see my article on API access in the free HubSpot CRM.
If none of these applies, you probably don't need custom development. If one clearly applies, the conversation about it is worth having.
What middleware actually does
The term middleware sounds more abstract than the thing is. It means a small custom application that sits between HubSpot and the other system and does the work neither side takes on.
It pulls data from one source, brings it into the shape the other side expects, and writes it there. In between is where the things that matter happen: fields get converted, edge cases get caught, duplicates get detected, a clear source of truth gets enforced when both sides know the same field. The middleware also remembers what it has already transferred, so a second run doesn't create everything twice.
This is exactly where it's decided whether an integration stays quiet in operation or causes constant trouble. An interface that only knows the ideal case runs on the day it's set up. One that can handle missing fields, a brief outage of the target system and an exceeded rate limit still runs half a year later. The difference rarely sits in the main function and almost always in how the exceptions are handled.
What to look for in a partner
Which brings us to the second question: who builds something like this, and how do you tell you've landed with the right one?
There are roughly three routes. A large integration agency brings process and capacity, but is often heavy and expensive for smaller connections. A single developer or freelancer is close to the code and flexible, but becomes a single point of failure when they're booked out or leave the project. A small specialised provider sits in between and is the most practical choice for most B2B cases, provided HubSpot and API work are genuinely the core business and not just one discipline among many.
More important than the category is what you watch for. Ask how they handle the topics I described above: how does the solution deal with rate limits? What happens when a run breaks off mid-way? How is it prevented that contacts get created twice? Anyone who answers these questions concretely rather than generally has built interfaces like this before.
Also pay attention to who owns the solution in the end. A good connection is documented, runs on your infrastructure or one you have access to, and can be maintained further by someone else too. An interface only its builder understands, sitting in an account you can't reach, is a risk no matter how well it works today.
And one last point that often gets lost: an honest partner will also tell you when you don't need custom development at all. Anyone who answers every request with "sure, we'll program that" earns on complexity. I'd rather suggest a ready-made integration or an n8n workflow when it does the job, and save the custom build for the cases where it's genuinely needed.
How I approach it
At Pipewave I build exactly these interfaces: from connecting a single API to middleware that links HubSpot with an ERP, accounting or a custom application. But I don't start with the code, I start with the question of whether it's needed at all. What such a connection looks like in a real project I show in the n8n-HubSpot workflows case study.
If you're facing exactly this decision, take a look at how I handle CRM integration and custom interfaces, or write to me through the contact form. Describe briefly which systems you want to connect and what should happen in between. I'll tell you honestly whether standard tools cover it or whether a custom interface pays off here.
Written by Joshua Kresse. At Pipewave I build HubSpot integrations and custom interfaces for B2B companies.