Salesforce Marketing Cloud Integration for SaaS Products

A SaaS product integrates with Salesforce Marketing Cloud in one of two ways, and the customer's edition decides which. For Marketing Cloud Engagement, the classic product, your product connects through an installed package inside the customer's Marketing Cloud account and calls its REST and SOAP APIs with OAuth 2.0. For Marketing Cloud Next, which runs on the core Salesforce platform with Data 360, you build on the platform itself and can ship a managed package. Marketing Cloud Connect, the bridge between a customer's CRM and Engagement, belongs to the customer. Your integration has to live with it, but it is not your integration.

For a SaaS company this is a product decision before it is an engineering one. Your customers' marketing teams want your product's data in their journeys, and every customer runs a different account structure, so whoever builds the integration also maintains it across all of them. Appnigma's done-for-you integrations team is one way to hand that off ("Build your product. We'll build the integrations."), with a named integration engineer and ongoing maintenance. If you are an admin connecting your own CRM to your own Marketing Cloud account, Salesforce's Marketing Cloud Connect Trailhead module is the better starting point.

Updated October 2026. Checked against the Marketing Cloud Engagement developer guide, the Marketing Cloud Connect help articles, the Marketing Cloud Next developer guide and the ISVforce security review guide. The earlier version of this post told SaaS teams to ship every Marketing Cloud integration as a Salesforce managed package, said middleware solutions cannot be listed on AppExchange, and said managed packages join Data Cloud automatically. None of that holds against the documentation, and the story it opened with can't be sourced. This version replaces them with the documented integration paths, the limits that shape them, and what security review asks of a Marketing Cloud app.

Which Marketing Cloud does your customer run?

Ask this before you scope anything. Salesforce now sells three products with Marketing Cloud in the name, and the developer guide is blunt about the difference. "Marketing Cloud Next, Marketing Cloud Engagement, and Marketing Cloud Account Engagement use different APIs that aren't compatible with each other," per Get Started with Marketing Cloud Next. The same page notes that the product formerly called Marketing Cloud is now Marketing Cloud Engagement.

Customer runs	Where your code runs	What you ship	APIs you call
Marketing Cloud Engagement	Your servers, plus optional UI hosted by you	An installed package with an API Integration component	Engagement REST and SOAP APIs on the customer's tenant endpoints
Marketing Cloud Next (Growth or Advanced)	The customer's Salesforce org	A managed package, with Data 360 metadata in a separate data kit package	Salesforce REST, Bulk and Data 360 Connect APIs
Marketing Cloud Account Engagement (formerly Pardot)	Scoped separately	A separate integration, not covered in this guide	Account Engagement API, which doesn't work with the other two

Many enterprise customers run Engagement with Marketing Cloud Connect linking it to Sales Cloud. That raises a second question your sales engineer should ask early, which is whether your product writes to the customer's CRM and lets their sync carry the data across, or writes straight into Engagement. The sections below cover both.

Marketing Cloud Next is the newer path, and Salesforce has opened it to partners. Its ISV announcement describes "Next Gen Marketing Cloud for ISVs, now generally available in Growth and Advanced editions," built natively on the core platform (Salesforce blog). Extensions there are built with "an Apex controller with a secure callout and a Lightning web component" (Build Extensions for Marketing Content), which is ordinary Salesforce package work.

How a SaaS product connects to Marketing Cloud Engagement

Engagement integrations are built from packages created in the customer's Marketing Cloud Setup, not Salesforce managed packages. Salesforce describes them as the way to "create API integrations, install custom apps, or add custom Journey Builder components" (Packages). A package can hold an API Integration component, an app shown in an iframe, Journey Builder activities and entry sources, and custom content blocks (Create and Install Packages).

Most SaaS products start with a server-to-server API integration. Your backend exchanges the client ID and secret for an access token at the customer's own authentication host. This is the request shape from Access Token for Server-to-Server Integrations, with placeholder values.

POST https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
Content-Type: application/json
{
  "grant_type": "client_credentials",
  "client_id": "<client id from the installed package>",
  "client_secret": "<client secret>",
  "scope": "data_extensions_read data_extensions_write journeys_read",
  "account_id": "<MID of the target business unit>"
}

Five details in that request matter more for a multi-customer product than for a one-off build.

The subdomain is different for every customer. Salesforce says "you must use your tenant-specific endpoint to interact with the APIs," and the subdomain is "a 28-character string that begins with the letters mc" (Your Subdomain and Tenant's Endpoints). Store it per customer next to their credentials.

Tokens are scoped to one business unit (an account inside the customer's Marketing Cloud enterprise). "Access tokens and refresh tokens act in the context of a single business unit," per OAuth 2.0 API Integration Considerations. The account_id field is how you switch, and only server-to-server integrations can be enabled for all business units at once (Manage Licensing for Installed Packages).

Tokens last 20 minutes and should be reused. The same token page says not to "request a new access token for every API call you make," because doing so is inefficient "and causes throttling." The arithmetic shows why. Reusing a token for its full life means at most 72 token requests per business unit per day. A product that fetches a fresh token per call and makes 10,000 calls a day sends 10,000 token requests on top of the real work.

Ask only for the scopes your features use. The scope names in the example come from Salesforce's REST permissions and scopes list, and security reviewers and customer admins both read them.

Some choices are permanent. "After you add an app or API integration component, it can't be removed from the installed package" (Create and Install Packages), and a package holds one API integration. Decide the integration type and scopes on paper first.

Getting your events into Journey Builder

Journey Builder is where your product's data turns into marketing action, and there are two documented ways in. The first is an entry event. Your product posts a contact key, an event definition key and the event data to POST /interaction/v1/events, and the API checks every field against the data extension (a Marketing Cloud data table) behind the event (POST /interaction/v1/events, Fire an Entry Event). A missing field throws a validation exception, so a customer who edits that data extension can break your sends without touching your code.

The second is a custom activity, a step marketers drag into a journey that calls your product. You host its interface and endpoints yourself, on "a web server that communicates via SSL (port 443)," and register it in the installed package (Build Custom Activities and Events). The same page states that "Salesforce Customer Support doesn't provide support for your custom Journey Builder events and activities." When a journey stalls on your step, the customer's ticket comes to you, so plan monitoring and an on-call path before you ship one.

What Marketing Cloud Connect changes for your integration

Marketing Cloud Connect is a managed package the customer installs in their Sales or Service Cloud org (Install the Marketing Cloud Connect Managed Package). If your product writes records into the customer's CRM, Connect may carry them into Engagement on its own schedule. That is convenient, and it has three side effects your customers will ask you about.

Synced records count toward the customer's contact total. Contacts, leads and users from synchronized data sources appear in All Contacts, and Salesforce says "these records are for billing purposes" (Contact Definition and Count Determination). Trailhead adds that every synced contact or lead counts "even if you've never sent them a message" (Synchronized Data Source Creation). As a worked example, a product that creates 40,000 leads in a CRM where the admin syncs the Lead object has added 40,000 records to that customer's billed contact count. Tell them before they turn it on.

Sync timing is the customer's setting, not yours. Admins choose the frequency in a Poll Schedule (Create Synchronized Data Sources), which Trailhead describes in "minutes or hours." Any object that meets the replication criteria and has a CreatedDate field can sync, so custom objects from your package can be included too. If your use case needs a journey to fire within seconds, an entry event from your backend is the documented path, not the CRM sync.

Field counts are capped. Salesforce recommends "no more than 20 fields per object" and a maximum of 250 (Synchronized Data Sources Best Practices). Keep the fields your product adds to a CRM object few and named for marketing use.

Subscriber keys follow the CRM IDs. Connect converts "the Contact ID, Lead ID, and User ID" into the 18-digit subscriber key stored in Engagement (Subscriber Key). If your product also writes contacts directly into Engagement, use the same 18-digit ID as the contact key, or the customer ends up with two contacts for one person.

Multi-Org accounts

Some enterprise customers connect several business units to separate Salesforce orgs, a configuration called Multi-Org. It is requested through Support, and Salesforce examines the account first. It also can't be reversed. "After your account is upgraded to Multi-Org, you can't turn it off," per the Multi-Org FAQs. Multi-Org needs an Enterprise 2.0 account, and connections are managed per business unit because "parent-mapping inheritance isn't currently supported."

For your product, the practical effect is that one customer can mean several business units, each tied to a different CRM org. Salesforce supports "up to 5 business units to the same Salesforce system user" in that setup (Multi-Org Account Configuration). Your data model should map each business unit to its own credentials and CRM org rather than assume one account per customer.

Where a managed package fits, and where it doesn't

A Salesforce managed package is the right delivery format for the CRM side of your integration and for Marketing Cloud Next. It is not how Engagement apps are delivered, because data extensions, journeys and installed packages live in Marketing Cloud, outside the Salesforce org. Many SaaS products need both pieces, a managed package in the CRM for objects, setup screens and record-level features, and an installed package in Engagement for sends and journeys.

Data 360 needs its own packaging work too. "To package Data 360 metadata components, first add the components to a data kit. Then add the data kit to a package," and since Winter '25, mixing Data 360 metadata with other metadata in one package "isn't allowed" (Packages and Data Kits). A managed package does not put your product's data into a customer's unified profiles by itself. Marketing Cloud Next starts from Data 360 as well ("first deploy data kits in Data 360," per Configure Your Marketing Cloud Next Org), so an ISV targeting Next should plan the data kit from the start. Our post on Data 360 provisioning for ISVs covers the org setup side.

Listing a Marketing Cloud app on AppExchange

Marketing Cloud Engagement apps can be listed, and they go through security review like other solutions. The ISVforce guide says managed packages, "Salesforce Platform API solutions, or Marketing Cloud Engagement API solutions" must pass review to be distributed (Security Review Guidelines). Salesforce's partner documentation now calls the marketplace AgentExchange.

What you submit is different from a managed package review. The required materials table has a separate Marketing Cloud App column that asks for scan reports of your external endpoints and "credentials to Marketing Cloud environment," and it does not require a managed package. Salesforce requires scans of "all external endpoints that run independently of the Salesforce platform," using any DAST (dynamic application security testing) scanner you prefer (Source Code Scanner on the Portal). Your custom activity server and token store are in scope.

Our AppExchange listing guide walks through listing types, and the security review guide covers preparation. For a combined CRM and Engagement product, expect both the managed package and the external endpoints to be reviewed.

Mistakes that break Marketing Cloud integrations after install

These are the failures customers report after go-live, each tied to documented behavior.

One credential set for every business unit. Tokens act in one business unit at a time. A product that stores one token per customer writes to the wrong business unit, or fails, once the customer has more than one.
A new token on every call. Salesforce says this causes throttling. Cache the token and refresh it shortly before its 20 minutes run out.
A hardcoded API host. Every customer has their own subdomain. Read it from the installed package details at onboarding and store it with their credentials.
Treating HTTP 500 as an outage. When SOAP traffic affects performance, Engagement "temporarily throttles subsequent SOAP API calls" and returns HTTP 500 errors (Rate Limiting). For REST, Salesforce says to watch for 429 responses (Prevent Rate-Limiting). Back off and retry instead of paging your on-call engineer.
Email as the contact key. Connect keys contacts by 18-digit CRM ID. Writing the same person by email creates a second contact, and a second billed record.
Syncing every field. Salesforce warns that syncing more fields "slows performance." Ship a default field set of 20 or fewer.
Assuming Salesforce Support covers your custom activity. It doesn't, so customers need your support path in the activity's own help text.

Should you build it in-house or hand it off?

Build in-house when Marketing Cloud is central to your product and your team will own the installed package, custom activity hosting and security review for years. That path gives you full control, and it is the right call for a marketing technology product whose roadmap depends on deep Journey Builder features.

Hand it off when the integration is a sales requirement rather than your product. The work is real either way, because there is per-customer onboarding and token handling, plus review and ongoing fixes as Marketing Cloud ships three releases a year (release schedule). An existing iPaaS or middleware setup can stay where it already meets requirements, and Appnigma's done-for-you page says the same. Appnigma's integration infrastructure suits teams that want their own engineers to write the logic, with authorization and per-customer connection monitoring handled on Appnigma's infra. For a native Salesforce app and listing, the marketplace apps team builds the managed package and supports review, and Salesforce controls review timing.

Frequently Asked Questions

What is Marketing Cloud Connect?

It is a managed package that links a customer's Sales or Service Cloud org to their Marketing Cloud Engagement account, syncing CRM records on an admin-set schedule and returning email tracking to CRM records.

Can Multi-Org Marketing Cloud Connect be turned off?

No. Salesforce's Multi-Org FAQ says "you can't turn it off" once an account is upgraded, and Multi-Org must be requested from Support.

Does Marketing Cloud Engagement have API rate limits?

Salesforce doesn't publish a fixed quota. SOAP calls that affect performance are throttled with HTTP 500 errors, REST clients should watch for 429 responses, and tokens should be reused for their 20-minute life.

Can a Marketing Cloud app be listed on AppExchange without a managed package?

Yes. Engagement API solutions go through security review with their own Marketing Cloud App submission materials, which include scans of your external endpoints.

Can Appnigma build our Marketing Cloud integration?

Appnigma's done-for-you team lists Salesforce and HubSpot as core specialties and scopes other systems and custom APIs case by case. Its marketplace apps team builds managed packages for the Salesforce side.

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.

Salesforce Marketing Cloud Integration Guide for SaaS Teams

Which Marketing Cloud does your customer run?