Updated June 18, 2026 by Sunny Chauhan.

I get the same question from SaaS founders every month: "Should we build a HubSpot integration ourselves or use a connector service like Tray or Workato?" The honest answer depends on three things: how many of your customers actually use HubSpot, how deep the integration needs to go, and whether you'll need a Marketplace listing for enterprise procurement. For most B2B SaaS products with 30%+ HubSpot customer overlap, building a custom integration is worth it. Here's the actual build guide: architecture, OAuth, data sync patterns, the failure modes I keep seeing, and the build-vs-buy decision framework.

Pro Tip

TL;DR A HubSpot custom integration is a server-side integration you build yourself between your SaaS product and HubSpot's APIs. Architecturally: OAuth for auth, REST API for reads/writes, webhooks for real-time change detection. Build it when you have 30%+ HubSpot customers, need deep data sync, or want a Marketplace listing. Use a connector platform (Tray, Workato, Workato Embedded) when integration is shallow or you want speed-to-market over control. Custom build cost: $40K-$120K for a v1 with one engineer over 3-6 months. Connector platforms: $30K-$150K per year ongoing.

Three signals that say build custom:

→ HubSpot is a top-3 CRM your customers use. If 30%+ of your install base runs on HubSpot, owning the integration is worth the investment. You'll be touching it constantly.

→ The integration needs to be deep. Real-time bidirectional sync, custom UI surfaces inside HubSpot (App Cards), CRM-side actions that trigger your product. Connector platforms can do these but charge for them and force you to maintain logic across two systems.

→ You want a HubSpot Marketplace listing. Listed apps must pass certification, which includes OAuth, signature verification, rate-limit hygiene, and webhook reliability. A connector platform won't get you certified; you need a real product-side integration.

Three signals that say use a connector platform instead:

1/ HubSpot is a small fraction of your customer base. If 8% of customers use HubSpot, building from scratch isn't worth six months of engineering.

2/ The integration is shallow. You want to push contact creation events one way and that's the whole feature.

3/ You don't have an engineer with API integration experience. Connector platforms abstract OAuth, retries, and webhooks. Hiring an engineer to do it from scratch is more expensive than the platform fee.

A typical HubSpot custom integration has four parts:

1/ OAuth service. Handles the install flow, exchanges authorization codes for tokens, manages token refresh, deletes tokens on uninstall.

2/ Sync engine. Reads from HubSpot via REST API (CRM objects, properties, associations), writes to HubSpot via REST API, respects rate limits.

3/ Webhook handler. Receives push events from HubSpot when CRM data changes, queues them for async processing.

4/ Mapping layer. Translates between your product's data model and HubSpot's CRM object model. Handles custom properties, custom objects, and field type mismatches.

The dataflow:

`` Customer installs your app → OAuth service captures tokens → Initial sync engine pulls baseline data from HubSpot → Webhook handler subscribes to ongoing changes → Subsequent CRM changes flow through webhooks → Your product's CRM changes flow through sync engine writes → Mapping layer translates both directions ``

Each component is independently deployable, scalable, and observable. Don't combine them into a monolithic "HubSpot service"; failure modes compound.

→ Create a HubSpot Developer Account → Create your app inside the Developer Account → Define your scope list (start minimal, see our scopes guide) → Implement the OAuth flow: authorize URL, callback handler, code-for-token exchange → Store tokens encrypted at rest, indexed by portalId → Implement token refresh (refresh before expiry, handle rotation) → Implement uninstall webhook handler that deletes tokens

Output of this phase: your app can be installed via OAuth and you can call HubSpot APIs with a valid token.

→ Implement read operations for the CRM objects you need (contacts, deals, etc.) → Implement write operations with batch endpoints (not one-record-at-a-time) → Implement the mapping layer between your product's model and HubSpot's → Add a per-portal rate limiter (token bucket, 100 tokens / 10 seconds) → Build an initial sync routine that pulls baseline data when a customer first installs

Output: an authenticated customer's HubSpot data flows into your product, and updates from your product write back to HubSpot.

→ Configure app webhooks in your Developer Account for the CRM objects you sync → Implement webhook signature verification (X-HubSpot-Signature-v3) → Implement the ack-fast-process-async pattern (return 200 within 5 seconds, queue for worker) → Wire webhook events through the mapping layer to your product → Make webhook handlers idempotent (HubSpot retries; you don't want duplicates)

Output: when a HubSpot CRM record changes in a customer's portal, your product knows within seconds.

→ Build App Cards if you need in-HubSpot UI surfaces (see our App Cards guide) → Audit scope usage; remove unused scopes → Add observability for 429 rate, webhook success rate, sync errors → Record demo videos for certification submission → Get 3 installs (one customer + two sandboxes works) → Submit to certification

Output: a certified Marketplace app or an internal integration ready for production.

That's 8 weeks with one experienced engineer. New-to-the-stack engineers should expect 12+ weeks.

The team builds without a rate limiter. Initial customers have small data volumes; everything works. The first enterprise customer with 50K contacts triggers a sync storm that 429s constantly. Customer complains. Team scrambles to add a limiter retroactively. Painful.

Fix: ship the rate limiter in week 3-4, not after the first incident.

Tokens go into a Postgres column without field-level encryption. Initially fine because no one notices. Then certification asks how tokens are stored. Then a security review board (yours or the customer's) asks the same. Then you migrate everything.

Fix: encrypted at rest from day one. AWS Secrets Manager or field-level encryption in the DB. See our API key management guide.

The team uses a cron job that polls for changes every 5 minutes. Works for 10 portals. Breaks the daily API cap when you have 200. Switches to webhooks midway through scale-up, fights through the migration with active customer data flowing.

Fix: webhook-first from week 5-6. See our webhooks guide.

A decision table:

The wrong answer for either side: building custom when you have 5% HubSpot overlap and shallow needs (expensive, slow, distracting). Or using a connector platform when you have 60% HubSpot overlap and want a Marketplace listing (you're paying the platform AND blocked from certification).

At Appnigma we generate Salesforce 2GP Managed Packages from natural-language prompts. The same architectural questions (OAuth, sync, webhooks, certification) apply to HubSpot. We're not yet generating HubSpot apps but the patterns are documented enough that we can guide founders through the build sequence.

For founders evaluating "build vs buy" specifically for HubSpot, my honest read in 2026: if your eng team is small (under 5 engineers) and HubSpot is meaningful but not dominant in your customer base, a connector platform buys you time. If HubSpot is a strategic surface for you, build it.

• [ ] Validated HubSpot customer overlap is 30%+ of your install base → Yes / No

• [ ] Identified the depth of integration required (read-only, bidirectional, in-app UI) → Yes / No

• [ ] Decided whether a Marketplace listing is on the roadmap → Yes / No

• [ ] One engineer allocated full-time for 3+ months → Yes / No

• [ ] HubSpot Developer Account created → Yes / No

• [ ] Initial scope list drafted (minimum viable) → Yes / No

• [ ] Decision on token storage approach (secrets manager vs field-level encryption) → Yes / No

• [ ] Plan for webhook-driven change detection (not polling) → Yes / No

• [ ] Sandbox accounts created for testing → Yes / No

A CPQ product (Salesbricks-analog) had 35% of their install base on HubSpot and wanted to ship a Marketplace listing.

→ Week 1: Developer Account, app skeleton, OAuth flow. → Week 2-3: Token storage in AWS Secrets Manager, refresh logic, uninstall handler. → Week 4-5: CRM read/write with batch endpoints, rate limiter, mapping layer for their quote-to-deal logic. → Week 6: Webhook handler for deal.propertyChange (their main trigger). → Week 7: App Card rendering current quote on the deal record. → Week 8: Demo video, 3 sandbox installs, scope audit. → Week 9: Certification submission.

Cert approved 4 weeks later. Total elapsed: 13 weeks from kickoff to live listing. Total eng cost: roughly $55K (one senior engineer at $200K/year fully-loaded, 13 weeks × 80% time on this).

A server-side integration you build yourself between your SaaS product and HubSpot's APIs, as opposed to using a connector platform like Zapier, Tray, or Workato. Architecturally: OAuth for auth, REST API for reads/writes, webhooks for real-time change detection. Necessary if you want a Marketplace listing.

For a v1 with one mid-senior engineer over 3-6 months, expect $40K-$120K in fully-loaded eng cost. Ongoing maintenance adds another 10-20% engineer time per year. Connector platforms cost $30K-$150K per year in subscription fees instead.

8-12 weeks with one experienced engineer who has API integration experience. Add 30-50% if the engineer is new to HubSpot or to OAuth in general. Certification adds another 3-6 weeks after submission.

Build when HubSpot is 30%+ of your customer base, the integration is deep, and you want a Marketplace listing. Use a connector platform when HubSpot overlap is smaller, the integration is shallow, or speed-to-market trumps control.

Limited. Connector platforms (Zapier, Make, Workato) let non-engineers configure surface-level integrations. For a custom server-side integration with OAuth, webhooks, and rate limiter, you need an engineer. No-code platforms for HubSpot app generation exist but are less mature than the Salesforce equivalent.

For most CRM-syncing apps: oauth, crm.objects.contacts.read, and one or two object scopes specific to your app's job (e.g., crm.objects.deals.read if you read deals). Add writes only when you actually write. See our HubSpot OAuth scopes guide.

Strongly recommended for any production integration. Polling instead of webhooks consumes API rate limits at high volume and gives stale data to users. Webhooks deliver changes in seconds and don't count against the per-portal rate limit.

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. Appnigma has helped B2B SaaS companies including Warmly, Hyperbound, Pylon, Seam AI, and Avoma ship native Salesforce Managed Packages. The architecture patterns described above for HubSpot map directly to the Salesforce ISV patterns Appnigma generates.

Originally published June 18, 2026. Last reviewed June 18, 2026. Build timelines, cost ranges, and architectural patterns based on Salesforce ISV experience adapted to HubSpot specifications current as of the published date.

• HubSpot API: Complete Builder's Guide

• HubSpot Webhooks Implementation Guide

• HubSpot OAuth and Scopes Complete Reference

• HubSpot API Key Management Guide

• HubSpot API Rate Limits Guide

• HubSpot App Cards and UI Extensions

• HubSpot Integration Platform Architecture Patterns

1/ HubSpot Developers, OAuth Quickstart Guide 2/ HubSpot Developers, CRM API Reference 3/ HubSpot Marketplace Certification Requirements 4/ Truto, How to Build a HubSpot Integration 2026 Architecture Guide

What's your customer's HubSpot overlap, and what does the math say about build vs buy in your specific case?