Connect your SaaS to Salesforce and HubSpot

Your customers keep asking for a native Salesforce or HubSpot integration inside your product, and every time the answer is "it's on the roadmap," someone on your team quietly starts scoping what it would take to build it: per-provider OAuth, token refresh, rate limits, keeping up with two vendors' API changes, and doing all of that again for the next CRM a customer asks for. Paragon ships that native integration for 70% less engineering than building it in-house, with each of your customers authenticating their own Salesforce or HubSpot instance through a white-labeled portal embedded directly in your app, running under your own domain and branding rather than a Paragon-hosted page.

What "connect your SaaS to Salesforce and HubSpot" actually means

Paragon connects your SaaS to Salesforce and HubSpot through 130+ prebuilt connectors and a white-labeled Connect Portal: each of your customers OAuths their own CRM instance from inside your app, with the credential stored and refreshed per user. That is your product's own end users getting a native Salesforce or HubSpot integration, not an AI agent calling into a CRM on your behalf.

Concretely, a customer using your product clicks "Connect Salesforce" (or HubSpot) inside your app. They authenticate against their own org, with their own permissions, through an embedded flow under your own branding. From there, your application calls Paragon's abstracted actions and triggers for that connection instead of writing directly against the Salesforce or HubSpot API. The underlying token issuance and per-user credential isolation is the same primitive covered in managed multi-tenant authentication; this article stays on the CRM-specific surface: what you can build once that connection exists.

What you can build with prebuilt Salesforce and HubSpot actions

Paragon abstracts the Salesforce and HubSpot APIs into a set of ready-to-call actions, so your engineers write against one interface instead of two vendors' object models and versioned endpoints.

On the Salesforce side, the documented actions cover Create, Update, Delete, Get Record by ID, Get Records by List View, Search Records, and Search Records by SOQL query, each available against Contact, Lead, Opportunity, Task, and Account records or against any object generically, plus Deploy Custom Field and Deploy Custom Object. That last pair matters for CRM work specifically: most SaaS products eventually need to push data into a customer's custom Salesforce fields or objects, not just standard leads and contacts, and Paragon exposes that as a callable action rather than something your team reverse-engineers from Salesforce's metadata API.

On the HubSpot side, the documented actions cover Create, Update, Get by ID, Search, and Delete for Companies, Contacts, Deals, and Engagements (plus a generic record variant), and Get Contacts by List ID. Engagements cover the activity-logging use case (calls, emails, meetings) that most product-to-CRM integrations need alongside record CRUD, and Delete handles the other end of a record's life once your customer's workflow needs to remove something rather than just update it.

If a customer's workflow needs an endpoint outside that list, Paragon exposes direct API access to the underlying Salesforce or HubSpot method as a fallback, or the action can be requested and added to the connector catalog.

Keeping data in sync both ways

A one-way pull is not enough for most CRM integrations your customers ask for. If a sales rep updates a deal in Salesforce, your product needs to know without polling for it, and if your product creates or edits a record, that same rep needs to see it land in their CRM.

Paragon covers both directions. On the inbound side, webhook triggers push events to your application in near real time: New Record, Record Updated, Record Deleted, and Campaign Member/Opportunity Added on the Salesforce side; New Company/Contact/Deal, Company/Contact/Deal Updated, Record Deleted, and a dedicated Record Deleted for Privacy trigger for GDPR-driven deletions on the HubSpot side. On the outbound side, your app calls the actions above whenever your own product state changes. Paragon names this combined pattern Bidirectional Sync: building two-way syncs between your application and your customers' CRM data, with real-time webhook delivery on both legs rather than a scheduled batch pull.

Build vs. embed: the engineering cost of hand-rolling CRM auth

Building this yourself means solving the same set of problems for every CRM your customers ask for. Each provider needs its own OAuth implementation, its own token refresh cadence, its own rate-limit handling, and its own mapping between your data model and the provider's object model. Multiply that by however many customers connect their own instance, and you need per-tenant credential isolation so one customer's Salesforce token is never reachable from another's session.

Paragon's own numbers put the savings at roughly 70% less engineering to ship a native Salesforce or HubSpot integration compared with building it from scratch, since the OAuth flow, token refresh, and the action/trigger abstraction are already built and maintained. Copy.ai's CTO Chris Lu has described the alternative: hiring a dedicated integrations team in-house would have taken at least half a year, versus one engineer shipping multiple integrations in a few weeks on Paragon. Appsmith's VP of Engineering has described enabling a similar third-party integration, in their case Jira, in under an hour once the connector existed. Neither example is a Salesforce or HubSpot deployment specifically, but both point at the same underlying cost: the auth and API-maintenance work is what eats the timeline, not the business logic your team actually wants to write. That maintenance burden doesn't stop at launch: providers version and deprecate endpoints on their own schedule, the ongoing cost covered in keeping integrations working when third-party APIs change.

How Paragon fits into your product

A customer clicking "Connect Salesforce" inside your app touches four Paragon pieces before that connection does anything useful.

First, the white-labeled Connect Portal: dropped into your settings or onboarding flow with the Connect SDK, running under your domain and branding, so nobody lands on a Paragon-hosted screen. Full mechanics of the underlying per-user authentication model live in the multi-tenant auth article linked above.

Behind that portal, the customer authenticates against their own org, and Paragon stores the result as an isolated Credential tied to their user record, refreshed automatically so your team never touches a raw access token.

Once that Credential exists, your backend calls Create Record, Search Records by SOQL, Update Contact, and the rest of the action set above, scoped to that customer's connection, instead of writing against the raw REST API.

Last, bidirectional sync keeps both sides current: inbound webhook triggers notify your app the moment a record changes on the CRM side, and outbound action calls push your product's own changes back. Paragon's orchestration layer sequences retries and backoff when an upstream call fails, so a rate-limited Salesforce request gets retried rather than silently dropped, and a failed sync shows up in the event log rather than getting discovered by a customer first.