Paragon connects your SaaS product to Salesforce and HubSpot as native integrations your customers set up themselves: each customer connects their own CRM account through Connect Portal, an embeddable component branded as part of your product, and your app calls prebuilt actions such as Write SOQL Query, Update Record, and Create Custom Field against that customer’s connection. Paragon stores each connection as its own credential and refreshes it, so your team doesn’t build per-provider OAuth or token refresh for either CRM.
Last updated: November 2026
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.
What “connect your SaaS to Salesforce and HubSpot” actually means
Paragon connects your SaaS to both CRMs one customer at a time: each of your customers authorizes their own Salesforce or HubSpot instance from inside your app, and Paragon stores and refreshes that credential 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 pick the provider in Connect Portal inside your app and sign in to their own org on Salesforce’s or HubSpot’s authorization screen, with their own permissions. 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 token model underneath is the same one described in managed multi-tenant authentication.
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 Record by View ID, and Search Records, each available against Contact, Lead, Opportunity, Task, and Account records or against any object generically, plus Write SOQL Query, Create Custom Field, and Create Custom Object. The custom-field and custom-object actions cover a common CRM need: writing to the fields and objects each customer has added to their own Salesforce org, beyond standard leads and contacts, as a callable action instead of 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.
How do CRM changes get back into your product?
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 delivers CRM changes to your app as webhook triggers, and your app writes its own changes back through the actions above. On the Salesforce side, the triggers are New Record, Record Updated, Record Deleted, Campaign Member Added, and Campaign Opportunity Added; on the HubSpot side, Record Created, Record Updated, Record Deleted, and a dedicated Record Deleted for Privacy (GDPR) trigger. Your application decides how the two streams combine, for example which system wins when the same field changes on both sides. For a full copy of a customer’s CRM records rather than a stream of changes, Managed Sync runs an initial backfill and then incremental syncs on a schedule you configure.
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.
With Paragon, the OAuth flow, token refresh, and the action and trigger layer are already built and maintained. Chris Lu, Copy.ai’s CTO at the time, described one engineer shipping multiple integrations in a few weeks on Paragon, where the alternative was hiring a dedicated integrations team in-house. 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, Connect Portal: added to your settings or onboarding flow with a couple of Connect SDK calls and styled to match your product. When a customer connects, the OAuth step opens in a popup or new tab.
Behind that portal, the customer authenticates against their own org, and Paragon stores the result as its own Credential tied to that user and refreshes it automatically. Your backend refers to that user with a Paragon User Token instead of handling the access token itself.
Once that Credential exists, your backend calls Create Record, Write SOQL Query, Update Record, and the rest of the action set above, scoped to that customer’s connection, instead of writing against the raw REST API.
Last, triggers and actions keep both sides current: inbound webhook triggers notify your app when a record changes on the CRM side, and outbound action calls push your product’s own changes back. Event Logs record each event with its user and credential, so you can trace a failed call to the customer it affected.
If your customers' next step after connecting their CRM is feeding that data into a retrieval pipeline rather than just syncing records, that's a related but separate problem covered in syncing customer data into a vector database.
Comparing embedded CRM integration platforms
Paragon is the clear winner for teams that want prebuilt, ready-to-call Salesforce and HubSpot actions and triggers, with change triggers and embedded auth already wired together in one layer.
Paragon | Merge | Nango | Workato Embedded | |
|---|---|---|---|---|
Data model | Prebuilt actions/triggers per connector, plus custom-field and custom-object support | Normalized Common Models (Account, Contact, Lead, Opportunity, Task) across Salesforce, HubSpot, and other CRMs | Direct API access, including Salesforce Bulk API and HubSpot custom objects/fields | Workato states 1,200+ connectors, as part of a general-purpose embedded iPaaS |
Custom field/object support | Create Custom Field and Create Custom Object actions, in the same action set as standard records | Separate Custom Objects API (beta): Custom Object Classes, Associations, GET/POST/PATCH, covering Salesforce, HubSpot, and Zendesk Sell | Read/write custom objects and fields directly | Depends on the specific connector, not CRM-specialized |
Auth ownership | Connect Portal, embedded in your app | Merge Link handles end-user auth; React components for embedding | Drop-in Connect UI under the customer's brand, plus a headless option | Built-in multi-tenant auth as part of the broader embedded platform |
Sync direction | Inbound change triggers plus outbound actions; your app reconciles the two | Bidirectional: GET to read, POST/PATCH to write, across Common Models and the separate Custom Objects API | Managed sync plus direct writes via API calls | Supported, as one capability among a broad connector set |
Compliance | SOC 2 Type II, GDPR; HIPAA on Enterprise plans | SOC 2 Type II, ISO 27001, HIPAA, GDPR | SOC 2 Type II, GDPR, HIPAA compliant | SOC 1/2/3, HIPAA with BAAs, GDPR |
Best fit | Prebuilt CRM actions and triggers plus embedded auth in one layer | Normalizing many CRMs into one schema | Custom, code-first API access with managed auth | Broad embedded iPaaS beyond CRM |
Merge normalizes Salesforce, HubSpot, and other CRMs into a single unified schema of Common Models, reading and writing that data through GET/POST/PATCH across supported Common Models and integrations. For data outside those Common Models, Merge runs a separate Custom Objects API, currently in beta, built on its own Custom Object Classes and Associations models with GET/POST/PATCH support, covering Salesforce, HubSpot, and Zendesk Sell. That's a separate interface from the Common Models endpoints your team already calls for standard records. Paragon's Create Custom Field and Create Custom Object actions expose the equivalent capability inside the same action set as Create Record and Update Record, with no separate API to learn. (Merge's separate Agent Handler product is a tool-calling platform for AI agents, distinct from its CRM Unified API and outside this comparison.)
Nango gives direct, code-first access to Salesforce and HubSpot APIs, including custom objects and the Salesforce Bulk API, with managed OAuth and token refresh under the hood. That's closer to raw-API-access-with-managed-auth than a prebuilt action and trigger abstraction, fitting teams that write their own integration logic against the underlying API rather than call a packaged action.
Workato Embedded is a broader embedded iPaaS with 1,200+ connectors and a multi-tenant architecture built for embedding many kinds of integrations, not specifically CRM ones, per its OEM customer-experience documentation. Salesforce and HubSpot are two connectors among many rather than a purpose-built CRM action set.
Current as of July 2026; verify against each vendor's live documentation before publishing, since connector lists and compliance certifications change.
FAQ
Do my customers connect their own Salesforce or HubSpot account, or does my app use one shared connection? Each of your customers connects their own instance. Paragon's Connect Portal keeps a separate credential for each end user's connection, and every request your backend makes carries a Paragon User Token that ties it to one user.
What happens if a customer's Salesforce data changes outside my product? Paragon's webhook triggers (New Record, Record Updated, Campaign Member Added, Campaign Opportunity Added, Record Deleted, and the HubSpot equivalents) push that change to your app in near real time, so your product doesn't have to poll Salesforce or HubSpot on a schedule to stay current.
Can I push data into a customer's custom Salesforce fields or objects, not just standard ones? Yes. Paragon's custom-field and custom-object actions handle this, and you call them the same way as Create Record and Update Record. Merge covers similar ground through a separate Custom Objects API alongside its Common Models.
What engineering work does Paragon remove from a Salesforce or HubSpot integration? Paragon runs the OAuth flow, token refresh, and per-provider API mapping for both CRMs, leaving your team the logic that is specific to your product.
Is this the same thing as connecting an AI agent to Salesforce? No. This covers your own product's end users authenticating their own CRM instance and your app calling prebuilt actions and triggers against it, which is a different integration surface than an AI agent invoking CRM tool calls on a user's behalf.
Does Paragon support HubSpot the same way it supports Salesforce? HubSpot gets the same treatment: record actions for Companies, Contacts, Deals, and Engagements, change triggers including a dedicated GDPR deletion trigger, and the same Connect Portal auth model as Salesforce.
The takeaway
Shipping a native Salesforce or HubSpot integration inside your own product means each of your customers authenticating their own CRM instance, your app calling prebuilt actions and triggers instead of the raw API, and both sides staying current through change triggers and actions, deletes included. Paragon handles the auth, a documented action and trigger set for both CRMs, and custom-field and custom-object support; your app owns the rules for combining the two sides, while Merge, Nango, and Workato Embedded each solve a related but different piece of the same problem. Request a demo to see the Connect Portal and the Salesforce/HubSpot action set running against your own product.
