Journeys & Automation
Exposes CXOS events and profile changes to external marketing-automation and journey-orchestration tools that own their own campaign logic.
High-Level Design
Journeys & Automation is the webhook path for tools that orchestrate their own campaigns.
💼 Business Context
- Lets external journey-orchestration tools (the marketing team's own campaign-builder platforms) react to CXOS events without CXOS needing to own campaign-logic itself
- Extends activation reach to whatever tool a business team already invests in, rather than forcing every activation use case through CXOS-native destinations
- Owned by Platform Engineering, subscriptions managed self-service by each integrating team
🔌 Technical Overview
A .NET Core webhook dispatcher (Docker container on Azure Container Apps) subscribes to qualifying event types on Azure Service Bus and delivers them as signed HTTPS POST callbacks to each registered subscriber endpoint, following the same event contract published via the Cxos.Ingestion.Client NuGet package so the payload shape is consistent with what was originally ingested. Each subscription's delivery state (success, retry count, last failure) is tracked as workflow state in Operational Services' Workflow Engine.
Webhook Events
💾 Webhook Subscription
{
"subscriber": "acme_journey_platform",
"event_types": ["profile.updated", "propensity.threshold_crossed"],
"endpoint": "https://hooks.acmejourney.example/cxos",
"signing_secret_ref": "kv://acme-webhook-secret"
}
🔗 Integration Points
- Azure Service Bus — event fan-out source for webhook delivery
- Cxos.Ingestion.Client contract — the shared event schema webhook payloads follow
- Workflow Engine (Operational Services) — tracks per-subscription delivery state and retries
- Azure Key Vault — stores per-subscriber signing secrets for payload verification
🧰 Services Consumed
- Owning microservice —
Cxos.Activation.Api(see the Full Application Service Map) - Database — Azure Cosmos DB (dispatch log) + Azure Cache for Redis (frequency caps)
⚠️ Non-Functional Considerations
- Scale: fan-out is designed for hundreds of concurrent subscribers without per-subscriber delivery becoming a bottleneck for any one
- Latency: webhook delivery typically completes within seconds of the source event, well inside the real-time activation SLA
- Reliability: failed deliveries retry with exponential backoff and are dead-lettered after a configured maximum, with the subscriber able to query missed-event state
- Security/Privacy: every payload is signed (HMAC) so subscribers can verify authenticity, and each subscription is entitlement-scoped to only the event types and fields it is approved for
🎯 Enterprise Example
A marketing team's third-party journey-orchestration tool subscribes to propensity.threshold_crossed events and builds its own multi-step win-back campaign entirely within that tool — CXOS supplies the trustworthy trigger, the journey platform owns the campaign logic, and neither team has to rebuild the other's functionality.