Marketing Cloud API & Integrations

Marketing Cloud API Integrations Built to Be Maintained

Marketing Cloud Engagement exposes a REST API and a SOAP API that share a common OAuth 2.0 authentication mechanism, with credentials issued from installed packages in Setup. Twopir Consulting builds against them with scoped credentials, explicit retry and failure behavior, and documented contracts — so the integration survives the person who wrote it.

Discuss an API Integration Integration Patterns

12+ Years of CRM and systems integration
40+ Certified Salesforce, HubSpot and AI specialists
15+ Certified platform partnerships

API Surface

Choosing

REST or SOAP? Default to REST, and Know Why You Did Not

Marketing Cloud Engagement offers both, sharing a common OAuth 2.0 authentication mechanism. REST provides broad access to capabilities throughout the platform; SOAP provides comprehensive access to most email functionality, including operations the REST surface does not expose.

REST and SOAP compared for Marketing Cloud integration
Consideration	REST API	SOAP API
Coverage	Broad access across the platform — data extension rows, journey entry, triggered sends, assets, contacts.	Comprehensive access to most email functionality, including subscriber and send operations the REST surface does not expose.
Authentication	OAuth 2.0, with a client ID and secret from an installed package.	OAuth 2.0, the same mechanism and the same package. This is not a reason to choose between them.
Developer cost	JSON, conventional verbs, straightforward to read and to debug.	XML envelopes, more verbose, a steeper path for a developer who has not met it before.
Where it fits	The default for anything new. Event-driven work, journey entry, data extension read and write.	When the operation genuinely is not available over REST, or when maintaining an existing integration that already uses it.
Maintenance	Easier to hand over. A new developer is productive quickly.	Heavier. Worth carrying where it is needed, worth avoiding where it is not.
Our default	Build new integrations here unless there is a stated reason not to.	Use deliberately, and write down which operation forced the choice — so a future developer does not have to rediscover it.

Capabilities verified against Salesforce developer documentation Last reviewed 23 September 2026

What Gets Built

Four Things People Build Against These APIs

Almost every Marketing Cloud API integration is one of these four shapes. Each has a characteristic failure mode, and naming it before the build is most of what makes the integration maintainable.

Shape 01

Scheduled server-to-server data movement

A backend system reads from or writes to data extensions on a schedule, with no user involved. The commonest shape and the one most often built without error handling, because it works on the day it is written.

Server-to-server integration using the client credentials grant
Batched writes sized against rate limits rather than against convenience
Idempotent operations, so a retry does not double-write
Explicit behavior when the platform is unavailable
Reconciliation: proof that what was sent is what arrived
Often better served by a file drop — see automation

Shape 02

Real-time journey entry and triggered sends

An external event starts a message or drops a contact into a journey — a failed payment, a shipment, a password reset. Latency-sensitive, customer-visible, and the shape where a silent failure is most expensive.

Journey entry events fired from your system as the event happens
Triggered sends for transactional and operational messaging
Queueing on your side, so a platform blip does not lose the event
Deduplication, so one business event produces one message
Alerting that distinguishes a rejected call from a dropped one
A documented position on what happens to events during an outage

Shape 03

Custom Journey Builder activities

The journey calls out to your service mid-flight and branches on the response. The direction is inverted — Marketing Cloud is the caller — which changes the failure analysis completely.

An activity that appears in the canvas alongside native ones
A documented request and response contract, versioned
Timeout behavior and a defined path when the call fails
No stranded contacts: every failure route ends somewhere
Your endpoint sized for journey volume, not for test volume
Built to the standards on the customization page

Shape 04

Reading data back out

Another system asks Marketing Cloud a question — engagement history, subscriber state, send results. Straightforward until volume grows, at which point the API is usually the wrong tool.

On-demand retrieval where freshness genuinely matters
Paging handled properly rather than assuming the first page is all
Bulk reporting volume routed to extracts, not the API
Caching on your side to keep call volume proportionate
Read-only credentials, scoped to read-only
A stated position on what a stale answer costs

Authentication

Installed Packages, Integration Types and Who Holds the Secret

Every API integration needs a client ID and secret, issued from an installed package created on the Installed Packages page in Setup. Enhanced packages support three OAuth 2.0 integration types, and choosing between them is a security decision rather than a convenience one.

Legacy package creation was deprecated in August 2019, so all new packages are enhanced packages. If you are maintaining something older, that is worth knowing before you plan around it.

What follows is the part that gets skipped, and it is the part that determines whether your integration estate is governable two years from now. Where the estate needs designing rather than governing, that sits inside the wider Marketing Cloud practice.

Server-to-server, web app, or public app

A server-to-server integration performs work on behalf of the integration itself, with no end-user context, user interaction or interface — the right choice for scheduled and system-driven work, using the client credentials grant. A web app acts on behalf of an end user where the client secret can be stored securely. A public app is for clients that cannot securely store a secret. Picking by habit rather than by what the integration actually does is how a batch job ends up carrying user-context permissions.

One package per integration, scoped to its own job

API integration permission scopes determine what a credential can reach. The failure we find in most estates is a single package used by everything, holding every scope, created by someone who has since left. One package per integration, scoped to exactly what that integration does, converts a single catastrophic credential into several boring ones.

Business unit access decided deliberately

A package can be scoped to specific business units, and in a multi-brand estate that matters as much as the permission scopes do. An integration built for one brand that can write to all of them is a governance problem waiting for an accident, and it is invisible until the accident.

Credentials owned by the organization, not a person

Rotation procedure documented, ownership assigned to a role rather than an individual, and secrets held where your security team expects them. The test is simple: if the person who built the integration left tomorrow, could someone rotate the secret without finding out what breaks by breaking it?

12+

Years delivering CRM and marketing platform transformation

15+

Certified platform partnerships

40+

Certified specialists across Salesforce, HubSpot & AI

98%

Client retention rate

Failure Modes

Four Ways an API Integration Stops Working Quietly

None of these throw an error anyone sees. That is what makes them expensive: the integration reports success, the data stops being right, and the discovery route is a customer.

All four are found by an audit of the integration layer, and all four are prevented by decisions made before the first line of code.

The credential nobody dares rotate — An integration authenticating under a package created by a former employee. Rotating it is the correct action and nobody will do it, because nobody can enumerate what depends on it. It sits on the risk register indefinitely.

Rate limiting handled as an error — Rate limits are a design constraint, not an exception. An integration that treats a throttle as a failure and abandons the batch loses data silently; one that retries immediately makes it worse. Back-off and resumption have to be designed in, and they are hard to retrofit under load.

The custom activity with no timeout path — Marketing Cloud calls your service, your service is slow, and the journey has no defined behavior for that case. Contacts strand mid-journey. Nothing alerts, because from the platform's perspective it is still waiting.

A contract that changed at the other end — Your service added a required field, or changed a response shape, and the integration was never versioned. It fails for a subset of records — usually the unusual ones — and the partial failure is invisible against a success count that still looks healthy.

When to Look

Signs Your API Estate Needs Governing

API integrations are built once, work immediately, and then are never looked at again until something breaks. These five signals are what an ungoverned estate looks like before that happens.

Review Your API Integrations

One installed package is used by several integrations, holds every scope, and was created by someone who has left.

Nobody can list the integrations authenticating into the org, so nobody can assess what a credential rotation would break.

An integration has no defined behavior for rate limiting, and its batch sizes were chosen for convenience rather than against the limit.

A custom Journey Builder activity calls a service with no documented timeout path, so a slow response strands contacts silently.

Integration failures are discovered by a customer or a campaign owner rather than by an alert.

Integration Patterns

The buyer-level view: Marketing Cloud Connect, the APIs, Data 360 and middleware, and when each is right.

Customization

Custom Journey Builder activities and the development standards they are built to.

Automation

File drops and scheduled work — frequently the better answer than an API for bulk movement.

Reporting & Analytics

Where bulk data retrieval should go instead of the API.

Audit

An inventory of packages, scopes, credentials and integration failure history.

Marketing Cloud Case Study

A worked example of the architecture-first approach on a real client engagement.

Common Questions

Questions About the APIs

How do we get API credentials for Marketing Cloud?

An administrator creates an installed package on the Installed Packages page in Marketing Cloud Setup, adds an API integration component, and the package issues a client ID and client secret. Those are what your integration uses to obtain an OAuth 2.0 access token.

The decision that matters at that moment is the integration type — server-to-server, web app or public app — and the permission scopes granted. Both are easier to set correctly than to narrow later, once several things depend on the package.

Should we use the REST API or the SOAP API?

Default to REST. It provides broad access to capabilities throughout the platform, it is materially easier to build against and hand over, and it is where new development should start.

Use SOAP when the operation you need genuinely is not available over REST — it provides comprehensive access to most email functionality, including some subscriber and send operations the REST surface does not expose — or when you are maintaining an existing integration that already uses it. Write down which operation forced the choice, so the next developer does not have to work it out.

What are the API rate limits?

They vary by edition, by endpoint and by contract, so a number published on a page like this one would be wrong for most readers. Check your own tenant and contract rather than relying on a figure quoted second-hand.

What matters architecturally is that you design for throttling rather than treating it as an error: batch sizes chosen against the limit, exponential back-off on a throttle response, resumption from where the batch stopped, and alerting that distinguishes a throttle from a genuine failure.

Can an external system start a journey?

Yes. The REST API supports firing a journey entry event, and triggered sends let an external system send a message directly. That is how a failed payment in a billing platform or a shipment update in an ERP reaches a customer in near real time.

The engineering is the easy part. The design questions are what happens when the same business event fires twice, what happens to events during an outage, and which system is authoritative when two of them disagree about a customer.

Should bulk data movement go through the API?

Usually not. For large scheduled movements, a file drop into Automation Studio is simpler, more resilient and easier to reconcile than a long sequence of API calls. Getting data out in bulk belongs in tracking extracts.

The API is the right tool when freshness matters — an event that cannot wait for the next scheduled window. Using it for bulk work produces an integration that is slower, more fragile and harder to reconcile than the alternative.

We inherited API integrations with no documentation. Where do we start?

With an inventory of the installed packages and what each one can reach. An audit establishes which packages exist, which scopes they hold, which business units they can touch, and — from request history — which are still in use.

That usually produces two lists: packages that can be retired immediately, and packages that need a documented owner and a rotation procedure before anyone touches them. Both are cheaper than the alternative, which is discovering the dependency by rotating the secret.

Next Step

Design the Failure Path Before the Happy Path

Tell us what has to move, in which direction, and how quickly. The interesting part of the conversation is always what should happen when it does not work.