Every integration you install is a set of permissions you granted, a share of a rate limit you now split, and a pile of records that will exist in your CRM long after you uninstall it.
Most of that is fine. Some of it is documented in places nobody reads before clicking Connect. And a few of the most expensive behaviours aren't documented at all — which is its own kind of answer.
Here are eight things worth checking first, with the source for each, and four more where HubSpot publishes nothing and you'll have to test it yourself.
This is the one that surprises people, and it comes straight from HubSpot's own developer docs. An OAuth access token is scoped to the portal and to the scopes the app requested — not to the permissions of the user who authorised it.
HubSpot spells out the consequence with its own worked example: a user restricted to viewing only their own contacts authorises crm.objects.contacts.read, and the resulting token can read every contact in the account. In HubSpot's words, access tokens "do not reflect the permissions or limitations of what a user can do."
What to check: the app's requested scopes, before install, not after. Super Admins can approve apps and restrict optional data permissions under Settings → Integrations → Connected Apps — but HubSpot is explicit that "required data permissions for apps cannot be modified or turned off." If a required scope is broader than you're comfortable with, the decision is install or don't. There's no middle setting.
One more governance gap worth knowing: App Marketplace Access permission is required for the first install of a public app. After that, other users can reinstall the same app without it, as long as no new scopes are requested.
Rate limits aren't per-integration in the way most teams assume.
Here's the part that matters: the per-10-second burst limit applies per app, but the daily limit is shared across every app in the account. Your new integration draws from the same daily budget as the six already running. Cross either limit and everything gets HTTP 429 until the reset, which happens at midnight in your account's timezone.
The CRM Search API is worse, because it's quieter. It carries its own limit of five requests per second, separate from your main allowance — and HubSpot documents that search responses "will not include any of the rate limit headers." You cannot see how close you are. Search is also capped at 200 objects per page, 10,000 results per query, and 18 filters, and newly created records aren't instantly searchable: "it may take a few moments for newly created or updated CRM objects to appear in search results." An integration that creates a record and immediately searches for it will sometimes find nothing.
What to check: how many apps are already installed, whether any of them poll, and whether the new one uses Search on a hot path.
If you take one thing from this article, take this one. It causes more surprise CRM growth than anything else on the list.
When you set up HubSpot data sync, the Filters section looks like an ongoing rule. It isn't. HubSpot's documentation: "The Filters section only limits which records initially sync between HubSpot and the third-party app." Once a record has synced, it keeps syncing both ways on the property mapping, filter or no filter.
Add that to the fact that historical sync isn't optional — on activation, "all existing records in both apps are passed through the sync engine" — and the shape of the problem is clear. You filter to a clean segment, the filter does its job once, and then the mapping runs forever on everything that got through.
What to check: what your filter actually admits on day one, because that's the population you're committing to.
When the same field changes on both sides, most people expect last-write-wins or a timestamp comparison. Data sync doesn't do that.
You choose a default app, and it overwrites the other on any discrepancy. That's it. One rule for the whole connection. And there's a quiet edge case: "if there's no field value in the default app, no data will be changed" — so a blank in your winning system doesn't clear the other side, it just does nothing.
Sync isn't instant either. HubSpot checks for changes every five minutes, and after the initial sync, records update within ten minutes of a change. Ten minutes is a long time for two systems to disagree about a deal stage.
What to check: which system genuinely owns each field, and whether one blanket winner survives that conversation. If it doesn't, you want a custom mapping — which needs Data Hub Starter or above.
Not as a bug. As documented behaviour: "when no match is found, the sync will create a new record in the other app."
Matching runs on defaults — email address for contacts and leads, company name or domain for companies, SKU or name for products. Any record without the matching key can't match, so it becomes a new record on the other side.
And a specific trap for anyone building a custom integration rather than using data sync: HubSpot automatically deduplicates companies by domain on manual creation, form submission and import — but "companies created through API will not be deduplicated by the Company domain name property." Your integration bypasses the safety net that the UI has.
What to check: how many of your records lack the match key, before you switch anything on. You can also define up to ten custom properties per object that require unique values, and use one as an alternate match key — that's usually the right answer when you're syncing against an ERP with its own IDs.
The classic failure: your integration writes a property, a workflow triggers on that property, the workflow writes back, the integration syncs it out, and round it goes.
HubSpot's only documented loop safeguard is narrow — if a workflow creates a record that then meets that same workflow's enrollment criteria, the action is skipped and logged as "the enrolled deal was created by this workflow, so this action was skipped to prevent an infinite loop." That's a useful guard for one specific case. It is not a guard for property write-backs across an integration boundary.
Two more mechanics that shape this:
What to check: every workflow whose enrollment trigger is a property your integration writes. That list is usually shorter than people fear and longer than they expect.
Certification is a real review — HubSpot's Ecosystem Quality team checks security, privacy, reliability, performance, usability, accessibility and value, and requires OAuth authorisation-code flow, a verified domain, a security assessment, and removal of scopes the app doesn't use. A certified app carries a badge. That's worth something.
It's worth knowing exactly what it isn't:
Separately, and more importantly for whoever signs the contract: HubSpot's Customer Terms of Service disclaims all liability for third-party products, and its data-hosting-location commitments explicitly don't extend to them. Under the DPA you are the Controller. So an EU-hosted portal tells you nothing about where a connected app sends the data you push into it.
What to check: the badge, the install count, and — for anything touching personal data — where that vendor actually processes it.
The best-documented case is the Salesforce integration, and it's instructive. Uninstalling removes the scaffolding: integration settings and the contact, company, deal and custom-object field mappings.
Everything the integration wrote stays. Contacts created from leads, companies from accounts, deals from opportunities, tasks, every property value, and the property groups it created. Salesforce workflow actions remain sitting inside your workflows — and no longer execute. Silently broken automation, still on the canvas.
There is better news for new apps: since May 2026, new submissions must implement an uninstall endpoint that removes app features and webhooks, and certification review now includes a demo of uninstall working.
What to check: before you install, ask the vendor what uninstall removes and what it leaves. Get the answer in writing, because HubSpot's docs won't give it to you for most apps.
Four behaviours matter a great deal and aren't published anywhere I could find. I'd rather say that than invent an answer:
All four are answerable in an afternoon in a sandbox. None are answerable from the marketplace listing.
HubSpot moved to date-based platform versioning on 30 March 2026, with an 18-month lifecycle and two major releases a year. That comes with hard dates:
What to check: which of your existing integrations are on a version with a date attached. This is the cheapest audit on the list and the one most likely to save a quarter.
We take the integrations most partners route around — HubSpot to ERP, to billing, to the routing layer — because that's where coherence actually lives, and because the failure modes above are the ones we've already hit on someone else's behalf.
The pattern in all eight risks is the same: the damage isn't caused by the app. It's caused by connecting a well-built app to a data model nobody agreed on, with permissions nobody read, on a rate limit nobody was tracking.
Architecture before automation. It's cheaper in that order.
Ten minutes, in this order: read the required scopes. Count the apps already drawing on your daily API budget. Decide which system owns each field. Check how many records lack a match key. List the workflows triggered by properties the integration will write. Ask the vendor what uninstall leaves behind. Then install it — in a sandbox first.
If you'd rather have someone do that pass with you, book the silent lead loss audit. We'll look at where inbound leads die between the form and the rep, what your integrations are doing to the records in between, and the one thing to fix first. We'll look at your HubSpot together and tell you straight whether we're the right fit. No deck. No pitch.
Private apps get 100 requests per 10 seconds on Free and Starter and 190 on Professional and Enterprise. Daily caps are 250,000 on Free and Starter, 625,000 on Professional and 1,000,000 on Enterprise. Publicly distributed marketplace apps are capped at 110 requests per 10 seconds per installing account, and the API Limit Increase add-on does not apply to them. The burst limit is per app; the daily limit is shared across every app in the account.
No. A HubSpot OAuth access token reflects the scopes the app requested, not the permissions of the user who authorised it. HubSpot's own documentation gives the example of a user restricted to their own contacts authorising contact read access, where the resulting token can read every contact in the account. The remote HubSpot MCP server is the exception — it respects existing user permissions.
Because unmatched records are created, not skipped. HubSpot data sync matches contacts on email address and companies on name or domain, and when no match is found it creates a new record in the other app. Records missing the match key can never match. Separately, companies created through the API are not deduplicated by the Company domain name property, so custom integrations bypass the dedupe that applies to manual creation, forms and imports.
Generally no, and HubSpot documents this for only one integration. Uninstalling the Salesforce integration removes settings and field mappings but leaves every record and property value it created, and Salesforce workflow actions remain in workflows without executing. Since May 2026 new app submissions must implement an uninstall endpoint that removes app features and webhooks, but that governs the app's own functionality, not the CRM data it wrote.
Certification means HubSpot's Ecosystem Quality team reviewed the app for security, privacy, reliability, performance, usability, accessibility and value. It requires at least 60 active unique installs, an average success rate above 95%, and renewal every two years. It is not a warranty: HubSpot's Customer Terms of Service disclaims liability for third-party products, and its data hosting location commitments do not cover them.
Read the required scopes, since required data permissions cannot be turned off after install. Count the apps already sharing your daily API limit. Decide which system owns each field before setting the data sync default app. Check how many records lack the matching key. List every workflow triggered by a property the integration will write. Ask the vendor what uninstall removes. Then test it in a sandbox.