One of the most recurring questions on ACC projects concerns the choice of integration pattern: should you use Adobe Campaign's REST or SOAP API, or build dedicated technical workflows? The answer isn't universal, it depends on context, volume, expected latency and existing architecture.
Here's what I've learned from connecting ACC with ESBs, MDM platforms and Snowflake on high-volume projects.
Adobe Campaign's API (REST since V7, historically SOAP) is the right choice in these situations:
If your ESB needs to trigger a transactional delivery in real time, order confirmation, alert, notification, the jssp/nms/interaction.jssp API or Message Center are the only coherent options. A technical workflow scheduled every N minutes introduces latency incompatible with this requirement.
When the MDM is the source of truth on customer data and updates must be reflected immediately in Campaign, a REST API push from the MDM is the cleanest pattern. It avoids polling loops and guarantees data consistency.
If your ESB (MuleSoft, IBM App Connect, WSO2…) is already the orchestrator of your integration flows, it makes sense to let it keep control. It calls ACC via API, handles retries, errors and traceability. Campaign doesn't need to know where the data comes from.
💡 Best practice: in V8, the REST API relies on the Snowflake engine in FFDA mode. Anticipate a few hundred ms of additional latency compared to V7 on unit calls. Prefer batching if volume is high.
Technical workflows remain the reference pattern for anything batch, scheduled or data-intensive:
The Database loading activity coupled with a Snowflake external account (FDA) allows importing large volumes in a controlled manner, with error handling, incident recovery and native Campaign execution logs. Far more robust than a looped API call.
When synchronisation doesn't need to be real-time, score recalculation, preference updates, consent consolidation, a nightly or morning scheduled workflow is more than sufficient and far more resource-efficient.
Business logic mixing segmentation, enrichment from external tables, pressure filters and target population building naturally belongs in Campaign workflows. Accessing it via API would be artificial and counterproductive.
| Criterion | REST/SOAP API | Technical workflow |
|---|---|---|
| Latency | Real-time | Batch / scheduled |
| Volume | Unit to medium | Very high volume |
| Orchestration control | Caller side (ESB) | Native Campaign |
| Monitoring / debug | ESB/MDM side | Native Campaign journal |
| Error handling | Retry on caller side | Native Campaign recovery |
| Setup complexity | Low | Medium to high |
| V8 FFDA compatibility | Increased latency | Natively optimised |
In practice, the architectures I encounter use both patterns in parallel. The ESB triggers real-time events via API, while batch synchronisations rely on scheduled technical workflows. Both coexist and complement each other.
The rule I apply: if latency is a constraint, use the API. If volume is a constraint, use the workflow.
⚠️ Watch out: in V8 with FFDA, workflows relying on local temporary tables (wkf_) must be revised. These tables are no longer local, they're in Snowflake. Behaviour can change significantly on intensive processing.
There is no universal answer to the choice between API and technical workflow. Both have their place in a mature ACC integration architecture. The key is to clearly define use cases, latency and volume constraints before choosing, and to document architectural decisions so the team that comes after you understands the rationale.
If you're designing or revising your Campaign integration architecture, I'm available to discuss it.
8 modules, 24 lessons for reliable production code: queryDef, JavaScript workflows, JSSP, webApps, APIs and deployment. Permanent access, fully commented code.
Discover the training →I can help you choose the right pattern and design a robust architecture. Reply within 24 hours.
Let's talk →