A SaaS company choosing how to integrate with HubSpot is really choosing whose HubSpot app its customers install. If buyers expect a Marketplace listing or your product on the HubSpot record page, that app has to be your own, registered under your name and authorized with your own OAuth client. Where its sync code runs, on your servers or on an embedded iPaaS, is a second and smaller decision. Zapier or Make flows suit low-volume jobs that each customer is willing to build and pay for.
This guide compares the five patterns SaaS teams use for a customer-facing HubSpot integration. For each one it shows who owns the app, which rate limit budget the traffic uses, whether it can be listed, and who has to migrate it before HubSpot's September 2027 cutoff. Appnigma is the author's company. It builds native HubSpot and Salesforce apps with listing preparation and review support, described on its page as "Your product, inside Salesforce or HubSpot." If you only need to connect HubSpot inside your own company, our guide to HubSpot integration types fits that job better.
Updated October 2026. Checked against HubSpot's developer docs, listing and certification requirements, and developer changelog on October 23, 2026. This update removes cost ranges, engineering estimates and a customer scenario we could not source. It corrects the claim that apps built on embedded iPaaS can never be listed, and it adds the per-account rate limit, the install caps and the 2027 end of support for legacy apps.
The five patterns side by side
Five patterns cover nearly every customer-facing HubSpot integration a SaaS company ships, and the column that separates them is the first one. Every API call a HubSpot integration makes is authorized by some app, and that app decides the listing, the rate limit budget and who receives HubSpot's deprecation notices.
| Pattern | Whose HubSpot app the customer installs | Where the sync logic runs | Rate limit budget in each customer account | Listed under your name |
|---|---|---|---|---|
| 1. Zapier or Make flows | The platform's app | The platform, configured by the customer | The platform's app budget, shared by all of that customer's flows | No |
| 2. iPaaS run by your team (Workato, Tray) | Usually the platform's connector | The platform, configured by your team | Depends whose OAuth client the connector uses | Only if it is your own app |
| 3. Your own Marketplace app | Yours | Your backend | Your app's 110 requests per 10 seconds | Yes, after review |
| 4. Embedded iPaaS or unified API | Yours, if the provider lets you bring your own OAuth client | The provider's runtime | Your app's budget if your client is used | Yes, if your client is used |
| 5. Hybrid | Yours for HubSpot, a platform's for the rest | Split | Your app's budget for HubSpot | Yes, for HubSpot |
The 110 figure comes from HubSpot's usage guidelines, which say each account that installs a Marketplace app "is limited to 110 requests every 10 seconds." That budget belongs to one app in one account, so two apps installed in the same account don't draw on each other's limit.
Zapier and Make flows that customers build themselves
In this pattern you publish an integration on Zapier or Make, and each customer builds the flow that moves data between HubSpot and your product. The customer installs the platform's HubSpot app, not yours. HubSpot's install guide uses Zapier as its example of a listing that needs a plan in the connecting product. It notes that "a Free, Starter, or Professional Zapier subscription is required." Zapier's pricing page bills in tasks, with 100 tasks a month on the Free plan.
This fits a product whose HubSpot need is one or two triggers, such as creating a contact when someone signs up. It costs your team the platform listing and nothing per customer. The limits show up in the sales cycle. A buyer who searches the HubSpot Marketplace finds no app under your name, every customer owns a slightly different flow, and your support team debugs setups it never built.
Workato or Tray recipes your own team runs
In the second pattern your team builds and runs the HubSpot integration on an enterprise iPaaS, usually one recipe or workflow set per customer. Workato describes its embedded product as a way to "build and maintain integrations for your customers," and Tray says "Tray maintains the connectors, so a change at Salesforce or Zendesk is handled below your integrations" (Tray Embedded). Workato shows no public prices and asks buyers to contact sales. Tray's pricing page says it "starts at $50 a month" and lists every higher plan as "Talk to sales."
The deciding question for HubSpot is whose OAuth client the connector uses. If it is the platform's shared HubSpot app, your customers install that app, and the integration can't be listed as yours. This pattern works best when HubSpot is one of many systems in a customer's workflow and your team needs orchestration across them more than a presence inside HubSpot.
Your own Marketplace app on your own backend
In this pattern you register a HubSpot app on the developer platform, customers install it with OAuth, and your backend runs the sync. It is the only pattern where every part, from the listing and scopes to the app cards and the migration schedule, sits with your company. Our step-by-step app build guide covers projects, OAuth and the listing in order.
What you get for that ownership is reach inside HubSpot. HubSpot's developer platform overview shows app cards, custom workflow actions and app settings available to Marketplace OAuth apps. App cards can appear on CRM records, preview panels and both the help desk and sales workspaces. That is what sales teams mean when they ask for your product inside HubSpot. One constraint shapes the backend. HubSpot's serverless functions are not offered to Marketplace apps, so the card and action handlers call endpoints you host through hubspot.fetch() or an actionUrl.
The rest of the work is also yours. HubSpot's listing requirements ask for OAuth as the "sole authorization method" and "at least three active, unique installs" from production accounts unaffiliated with you, and HubSpot completes "an initial review within 10 business days." Certification comes later. The certification requirements ask for six months listed, 60 active installs and a success rate above 95%. Since HubSpot's May 2026 changelog, they also include a security questionnaire on "encryption, access controls, and token lifecycle management."
Embedded iPaaS or a unified API behind your own app
Embedded iPaaS and unified API products run the connection for you. Customers click "Connect HubSpot" inside your product, and the provider handles OAuth, token refresh and API calls across many integrations from one place. For a product that must also reach Salesforce, Pipedrive and a dozen other tools, that breadth is the reason to use one.
For HubSpot, the setting that matters is whether the provider lets you supply your own OAuth client ID and secret. With your own client, customers install your app, the calls use your app's rate limit budget, and the integration can be listed under your name. With the provider's shared app, none of that holds. Merge's HubSpot setup article shows the first setup, telling customers to "create a Hubspot Application and enter its credentials within Merge." Our comparison of HubSpot integration providers covers the billing units of Merge, Paragon, Prismatic and others at 50 customers.
Depth is a smaller limit than it first looks. App cards and custom workflow actions are declared in your own HubSpot project and deployed with the HubSpot CLI, but the handler behind them is an HTTPS endpoint, and no HubSpot doc we found requires it to run on your own servers. What a provider can't give you is the project, the card UI code and HubSpot's review of them, so a team using one still owns a HubSpot app.
Can an app built on embedded iPaaS be listed on the HubSpot Marketplace?
Yes, if the listed app is your own. HubSpot's listing requirements say the app "must authorize API requests with the public HubSpot app ID (and OAuth client ID) associated with your app listing," and the listing "must not redirect to a different public or private app or require another public or private app to function." Neither rule names a backend, so an app whose sync runs on a provider's runtime meets them as long as every call carries your app's credentials.
What HubSpot bars is listing the infrastructure itself. Its Marketplace restrictions exclude "White-label integration infrastructure," defined as "apps with a HubSpot integration designed to be embedded invisibly into another party's product." The same page excludes credential and token brokering and apps that require "a third-party developer to build a separate product" before an end user gets value. The listing has to be your product, under your name, delivering "standalone value directly to end users."
What the rate limits mean for each pattern
HubSpot's API limits decide how fast a sync can move a customer's data, and they only become concrete with real numbers. This worked example uses HubSpot's documented limits. Take a customer with 200,000 contacts. The contacts API returns up to 100 contacts per request, so a full first read takes 2,000 requests. At 110 requests every 10 seconds, that is about three minutes of your app's budget in that account if nothing else is calling. Writing a field back to every record takes another 2,000 requests, because "batch operations are limited to 100 records at a time."
Ongoing syncs hit a different ceiling. The CRM search endpoints allow "five requests per second per account" and return up to 200 records a page. They are also "limited to 10,000 total results for any given query." A nightly job that searches for contacts changed since yesterday works until a customer bulk-imports 15,000 records. Past that point the query has to be split into smaller time windows, or the sync has to switch to webhooks.
Webhooks have their own shape. HubSpot's webhooks API guide is written for legacy public apps, and it describes batches of up to 100 events per request with a concurrency limit of 10. A response slower than five seconds counts as a failure, and HubSpot retries "up to 10 times." An endpoint that does the sync work before answering will start missing events at volume, so it should acknowledge first and queue the work.
When customers connect through Zapier, Make or an iPaaS on the platform's own app, none of this budget is yours to plan. All of a customer's flows on one platform share that platform's app budget in their account. A connection that runs on a privately distributed or legacy private app draws from a daily cap of 250,000 requests on Free and Starter, which HubSpot says "is shared across all apps within the same HubSpot account."
How to choose a pattern for your SaaS product
A SaaS company can choose its HubSpot integration pattern with four checks, starting with what buyers will look for. If enterprise prospects expect a Marketplace listing, or your sales team needs the product visible on HubSpot records, you need your own HubSpot app. That means a native app, an embedded provider running on your own OAuth client, or a hybrid. If prospects only need data moved now and then, a Zapier or Make integration costs you almost nothing to offer, and the customer owns the flow.
Then count the customers you expect. Per Manage apps in HubSpot, an unlisted Marketplace OAuth app "can be installed in up to 25 accounts," and a privately distributed app is capped at 10 allowlisted accounts. A roadmap with dozens of HubSpot customers next year means planning for the listing from the first build.
Next, count the other systems on your roadmap. If HubSpot is one of ten CRMs you must support, an embedded provider behind your own HubSpot app, or a hybrid, keeps the long tail manageable. If HubSpot is the main one, owning the backend avoids paying for breadth you won't use.
Last, decide who maintains it. If your engineers are committed to the core product, Appnigma's done-for-you integrations assign a named integration engineer who builds the integration and maintains it afterward. Teams that want to build it themselves can use Appnigma's integration infrastructure. In the page's words, "your engineers build the integration logic on Appnigma's infra," and each customer authorizes their own account with "their connection managed separately."
Who has to migrate each pattern before September 2027?
HubSpot's September 15, 2026 changelog ends support for v1 to v3 APIs and for legacy public and private apps. All of them have "a September 2027 enforcement date." Support for v4 ends earlier, on March 30, 2027. After the cutoff, an app on unsupported API versions "loses its certification status," and one on the pre-Projects architecture "is eligible for delisting."
Who carries that work depends on whose app the customers installed. Zapier, Make and iPaaS platforms update their own HubSpot apps, though customer flows that use older actions may still need edits. For your own Marketplace app or a hybrid the migration is yours. HubSpot says "public apps created before June 23, 2026 use HubSpot's pre-Projects app architecture," so an app that old has a migration on the roadmap now. With an embedded iPaaS or unified API, the provider updates its API calls, but your HubSpot project, cards and listing still sit with you. Apps on Projects 2025.2 or older also "need to migrate to the current version (2026.09) by March 2027."
Mistakes SaaS teams make when picking a pattern
- Listing on the provider's shared OAuth app. The listing has to authorize with its own app ID, so confirm your provider supports your own client before you build.
- Promising a HubSpot card from a Zapier integration. App cards belong to a HubSpot app, and a flow on someone else's app can't add one.
- Planning around serverless functions. HubSpot offers them to single-account apps, and installing one needs an Enterprise subscription, so a Marketplace app needs its own hosted endpoints.
- Requesting custom object scopes as required. HubSpot's scopes reference marks
crm.objects.custom.read"Available to Enterprise accounts only," so a required scope blocks installs on other tiers. Make it optional. - Testing the listing threshold on sandboxes. Only production accounts unaffiliated with your company and active in the past 30 days count toward the three installs.
Frequently Asked Questions
What is a HubSpot integration platform?
The phrase covers any product that runs the connection between HubSpot and other software, from Zapier and Make to Workato, Tray, embedded iPaaS and unified APIs. For a SaaS company, the question that matters is whether customers install your own HubSpot app or the platform's.
Can I list a HubSpot Marketplace app built with an embedded iPaaS?
Yes, if the provider lets you use your own OAuth client so every call carries your listed app ID. HubSpot doesn't list the provider's shared app as yours, and it excludes white-label integration infrastructure from the Marketplace.
Is Zapier enough for a HubSpot integration?
For a few low-volume triggers that each customer sets up, yes. It can't put your product on HubSpot records or give you a listing under your name, and each customer pays for their own Zapier plan.
Which embedded iPaaS is cheapest for a HubSpot integration?
It depends on the billing unit, since each vendor prices differently. On October 23, 2026, Nango listed a a month pay-as-you-go plan and Cyclr started at ,595 a month. Merge charged a month for 10 linked accounts plus for each one after, which works out to ,250 a month at 50 customers. Paragon and Prismatic quote on request.
How many customers can install a HubSpot app before it is listed?
Up to 25 accounts for an unlisted Marketplace OAuth app, and 10 for a privately distributed one, not counting developer test accounts. Listing needs three active installs from unaffiliated production accounts.
Can Appnigma build our HubSpot Marketplace app?
Yes. Appnigma's marketplace apps service delivers a native HubSpot app with listing preparation and review support, and its done-for-you service maintains it afterward. HubSpot controls listing approval and timing.
Related Articles
- How to build a HubSpot app
- HubSpot integration providers and services
- HubSpot integration types explained
- HubSpot app certification requirements
- HubSpot app cards and UI extensions
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Sources
- API usage guidelines and limits, HubSpot Developers
- App Marketplace listing requirements, HubSpot Developers
- Marketplace restrictions, HubSpot Developers
- Certification requirements, HubSpot Developers
- App listing and certification requirement updates for May 2026, HubSpot Developer Changelog
- Developer platform overview, HubSpot Developers
- App cards overview, HubSpot Developers
- Manage apps in HubSpot, HubSpot Developers
- Contacts API guide and CRM search, HubSpot Developers
- Webhooks API guide, HubSpot Developers
- Legacy APIs and legacy apps, what's going unsupported and when, HubSpot Developer Changelog
- Connect apps to HubSpot, HubSpot Knowledge Base
- Zapier pricing, Tray pricing and Tray Embedded, vendor pages
