Designing Reliable REST and SOAP Integrations with Marketing Cloud

Most Marketing Cloud integrations do not fail because someone picked the wrong API. They fail because nobody decided what happens on the second attempt.

Which API for which job

• REST: triggered sends, asset and content work, journey interaction, anything modern and anything you want to debug quickly.
• SOAP: bulk retrieves, certain configuration objects, and data extension operations with filtering that REST does not expose as cleanly.
• Neither: if the answer is a nightly file, a file drop into an automation is still an entirely respectable integration.

Authentication

Get one token, cache it, refresh it before expiry, and never mint a token per request. The rate limit you hit first in a naive integration is usually the auth endpoint, not the endpoint you care about.

Idempotency is the whole game

Any network call can succeed on the server and fail on the way back to you. If your retry then sends a second order confirmation, the customer notices. Upserts keyed on a stable business key are safe to repeat. Inserts keyed on an auto-generated id are not.

{
  "contactKey": "SAMPLE-001",
  "eventDefinitionKey": "sample-order-confirmation",
  "eventRequestId": "order-1042-attempt-1",
  "data": { "orderNumber": "1042", "total": "42.00" }
}

Retries that do not make things worse

• Retry on 429, 500, 502, 503, 504 and network timeouts. Do not retry on 400 or 401 without changing something first.
• Exponential backoff with jitter — synchronised retries are how a small outage becomes a big one.
• Cap the attempts and write the failure somewhere a human will look.

Error surfaces

Decide in advance who finds out when the integration breaks: the marketer, the platform team, or nobody until the campaign underperforms. That decision is architecture, and it is usually made by accident.

Illustrative patterns, not a substitute for the current Salesforce API documentation — check limits and endpoints against the official docs before building.