What Is a Retention Orchestration Layer? A Technical Overview for Engineering and Marketing Ops Teams

Your VP of Marketing wants an orchestration platform. Your job is to figure out what that actually means at the architecture level — what touches your data, what gets write access, what happens when it breaks, and how many engineering hours it will consume to implement and maintain.

This article is the technical companion to our broader overview of retention orchestration as a category [link to Article 01: What Is Retention Orchestration]. That piece explains the why. This one explains the how — API architecture, data flow model, integration patterns, failure modes, and security posture. If you are a Marketing Ops Manager, a Director of Engineering, or anyone responsible for evaluating whether a new platform belongs in your stack, this is the document you need.

---

The Technical Definition of an Orchestration Layer

An orchestration layer is middleware that sits between your existing tools and coordinates their behavior without replacing them. That sentence sounds simple. The architecture beneath it is not.

In traditional software architecture, an orchestration layer is a well-understood pattern. Service orchestration coordinates multiple microservices to execute a workflow. The orchestrator holds the logic. The services hold the capabilities. Neither needs to know about the other's internal implementation.

A retention orchestration layer applies this same pattern to your marketing and retention tool stack. Klaviyo holds email capabilities. Attentive holds SMS capabilities. Yotpo holds review and loyalty capabilities. Recharge holds subscription management capabilities. Gorgias holds support capabilities. The orchestration layer sits above all of them, reads signals from each, correlates those signals into a unified view, and coordinates actions across them.

The critical architectural distinction: the orchestration layer does not store your customer data. It does not replace your tools. It does not require data migration. It reads from your existing systems, processes signals in real time, and pushes coordinated actions back to those systems — each of which remains the system of record for its domain.

This is not a CDP. A CDP centralizes data. An orchestration layer centralizes coordination logic while leaving data where it lives.

This is not a marketing automation platform. Automation platforms execute rules within a single tool. An orchestration layer executes cross-tool strategies that no single platform can see.

This is not another integration. Integrations connect two tools. An orchestration layer connects all of them and adds intelligence to the connections.

---

Architecture Overview: Event-Driven, API-First, Read-Only Default

The architecture of a retention orchestration platform like Phleid rests on three foundational design decisions. Each one was made to solve a specific class of problems that emerge when you try to coordinate 28+ tools.

Event-Driven Processing

The orchestration layer operates on events, not batch jobs. When a customer cancels a subscription in Recharge, that event flows into the orchestration layer in near real-time. It does not wait for a nightly sync. It does not wait for someone to export a CSV. The event arrives, the system evaluates it against the current state of that customer across all connected tools, and it determines the appropriate coordinated response.

This is fundamentally different from how most martech integration works today. The standard pattern is periodic sync — pull data from Tool A every 15 minutes, push it to Tool B, hope nothing changed in between. Periodic sync creates lag. Lag creates missed opportunities. A customer who cancels a subscription at 2:00 PM and receives a win-back email at 6:00 AM the next morning has already moved on.

Event-driven architecture eliminates that lag. Events are processed as they occur. The orchestration layer maintains an event stream from every connected tool and processes those events through a correlation engine that understands the relationships between them.

In practice, this means the system processes thousands of events per hour across a typical mid-market DTC brand's stack. A product return in your returns platform, a support ticket in Gorgias, a loyalty point redemption in Smile.io, a browse session captured by your on-site personalization tool — each is an event, and each is evaluated in the context of everything else happening for that customer.

API-First Design

Every interaction between the orchestration layer and your tools happens through documented APIs. There are no database-level connections. No screen scraping. No brittle Zapier chains. API-first means the orchestration layer communicates with your tools the same way your tools communicate with each other — through their official, supported, versioned API endpoints.

This has three practical implications.

First, integration stability. When Klaviyo ships a new version of their API, the orchestration layer updates its integration module. Your configuration does not change. You do not need to rebuild workflows. The API contract is the boundary, and changes behind that boundary are the orchestration platform's problem, not yours.

Second, predictable behavior. API calls are logged, traceable, and auditable. Every action the orchestration layer takes is an API call with a request, a response, and a timestamp. If something unexpected happens, you can trace exactly what call was made, when, and what the response was. Compare that to debugging a chain of five Zapier automations that triggered in sequence, each with its own retry logic and failure behavior.

Third, compatibility breadth. API-first means the orchestration layer can connect to any tool that exposes an API — which, in 2026, is every tool in your stack. The 28+ integrations Phleid ships with are not custom-built connectors that took months to develop. They are API integration modules built against each tool's published API specification, maintained by an engineering team with direct expertise in each tool's data model and rate limits.

Read-Only Default

This is the design decision that matters most to you as a technical evaluator. By default, the orchestration layer operates in read-only mode. It reads data from your tools. It does not write to them.

Read-only default means the system can ingest events from Klaviyo, Attentive, Yotpo, Recharge, Gorgias, and every other connected tool without any risk of modifying data in those tools. It can build a unified view of customer behavior. It can generate recommendations. It can identify at-risk customers and high-value opportunities. All of this happens with read-only API access.

Write actions — sending an email through Klaviyo, triggering an SMS through Attentive, adjusting a loyalty tier in Yotpo, pausing a subscription in Recharge — require explicit opt-in. Per tool. Per action type. With granular permission controls.

This is not a checkbox you check once during setup. Write permissions are granted per integration, per action category, with full audit logging of every write action executed. You can grant the orchestration layer read access to all 28 tools and write access to none. You can grant write access to Klaviyo for email sends but not list management. You can start fully read-only, evaluate the system's recommendations for 30 days, and then selectively enable write actions as you build confidence.

The read-only default exists because the biggest technical fear when evaluating a new platform is: "what if this thing starts doing things I didn't authorize?" The answer is architectural, not contractual. The system cannot write to a tool until you explicitly grant that permission, and you can revoke it at any time.

---

Integration Patterns: How 28+ Tools Connect

Not all APIs behave the same way. A retention orchestration platform needs to handle three distinct integration patterns, because your tools use all three.

Webhooks (Push-Based)

Many modern SaaS tools support outbound webhooks — when an event occurs, the tool pushes a notification to a registered URL. Shopify does this well. Recharge does this well. Gorgias supports it for ticket events.

For webhook-capable tools, the orchestration layer registers webhook endpoints during setup. When a customer places an order on Shopify, Shopify pushes the event to the orchestration layer within seconds. When a subscription is cancelled in Recharge, Recharge pushes the cancellation event immediately.

Webhook integrations are the fastest and most efficient pattern. They minimize API call volume, reduce latency, and provide true real-time event flow. The orchestration layer receives events as they happen without needing to poll for changes.

The challenge with webhooks is reliability. Webhooks can fail — the receiving endpoint might be temporarily unavailable, or the sending tool might have a delivery issue. A well-architected orchestration layer implements webhook delivery verification, retry handling, and fallback polling for any events that might have been missed. Phleid's architecture treats webhook delivery as at-least-once and deduplicates events on the receiving end, so you never get duplicate actions from a single customer event.

API Polling (Pull-Based)

Some tools do not support webhooks for all event types, or their webhook implementation is limited. For these tools, the orchestration layer polls their APIs at configured intervals — typically every 30 seconds to 5 minutes, depending on the tool and the event type.

API polling is the fallback pattern. It is less efficient than webhooks because it requires the orchestration layer to make regular API calls even when nothing has changed. But it is universally compatible. Any tool with a REST API that supports querying by timestamp or cursor can be polled.

The orchestration layer manages polling intelligently. High-priority tools get polled more frequently. Low-change-frequency tools get polled less often. Rate limits are respected automatically — more on that in the failure modes section.

Event Streams (Streaming)

A growing number of tools support real-time event streams — persistent connections that deliver events as a continuous flow rather than as individual webhook pushes or poll responses. This is the most architecturally elegant pattern, and the one the industry is moving toward.

For tools that support streaming, the orchestration layer maintains persistent connections and processes events as they arrive on the stream. This combines the real-time nature of webhooks with the reliability of a managed connection.

The Integration Matrix

In practice, a typical mid-market DTC stack uses a mix of all three patterns. Here is what a representative integration map looks like:

• Shopify: Webhooks for orders, fulfillment, customer events. API polling for historical data backfill.
• Klaviyo: API polling for campaign performance and engagement data. Webhooks for flow events where supported.
• Attentive: Webhooks for SMS events. API for subscriber management data.
• Yotpo: API polling for reviews, ratings, loyalty data. Webhooks where available.
• Recharge: Webhooks for subscription lifecycle events. API for subscription state queries.
• Gorgias: Webhooks for ticket creation and status changes. API for ticket detail retrieval.
• Smile.io: API polling for loyalty program data. Webhooks for point events.
• Rebuy/Nosto: API polling for personalization engagement data.

The orchestration layer abstracts all of this away. From your perspective, every tool produces events. Whether those events arrived via webhook, polling, or stream is an implementation detail the platform handles. You configure which tools to connect, grant API credentials, and the platform determines the optimal integration pattern for each.

[link to Article 15: Klaviyo + Attentive + Yotpo Integration]

---

Data Model: No New Data Silo

This is the section that matters most if your concern is "are we creating another data silo?"

The short answer: no. The orchestration layer does not duplicate your customer data. It does not maintain its own customer database. It does not become yet another system of record that needs to be kept in sync with everything else.

Here is what the data model actually looks like.

Identity Resolution Layer

The orchestration layer maintains an identity graph — a mapping of customer identifiers across tools. Customer #45892 in Klaviyo is the same person as Subscriber #12047 in Recharge and Ticket Requester #8821 in Gorgias. The identity graph stores only these cross-references, not the customer data itself.

When the system needs to evaluate a customer's current state, it queries the relevant tools in real time using their APIs. It does not cache customer profiles. It does not store email addresses, purchase histories, or behavioral data in its own database. It stores the keys needed to find that data in your existing tools and queries for it on demand.

This is a fundamental architectural difference from a CDP. A CDP ingests your customer data and stores a unified copy. That copy needs to be kept in sync. It becomes stale. It introduces questions about which system has the "true" record. An orchestration layer avoids all of this by querying source systems at the moment of decision.

Signal Cache (Ephemeral, Not Persistent)

For performance, the orchestration layer maintains a short-lived signal cache. When events arrive, they are held in memory for the duration of signal processing — typically seconds to minutes. This cache enables real-time correlation (more on this below) without requiring round-trip API calls to every tool for every event.

The signal cache is ephemeral. It is not persisted to disk. It is not backed up. It does not contain PII. It contains event metadata — "customer X did action Y in tool Z at time T" — in a format that enables correlation without storing the underlying customer data.

After processing, the signal cache is cleared. The orchestration layer retains aggregated analytics (event counts, action outcomes, performance metrics) but not individual customer data.

What Gets Stored (And What Does Not)

To be explicit about what data the orchestration layer persists:

Stored:

• Cross-tool identity mappings (tool-specific customer IDs only)
• Configuration data (your integration settings, orchestration rules, permission grants)
• Action logs (what the system recommended or executed, when, and the result)
• Aggregated performance metrics (campaign-level and cohort-level, not individual-level)

Not stored:

• Customer PII (names, emails, phone numbers, addresses)
• Purchase histories
• Behavioral data (browsing, click tracking)
• Payment information
• Customer profiles

Your data lives in your tools. The orchestration layer reads it when needed and acts on it in real time. When someone on your team asks "where does our customer data live?" the answer does not change. It lives in Klaviyo, Recharge, Shopify, and the rest of your stack. The orchestration layer is a coordination brain, not a data warehouse.

[link to Article 09: DTC Martech Stack Optimization]

---

Signal Processing: Cross-Tool Correlation in Real Time

This is where the intelligence lives. Individual events from individual tools are useful. Cross-tool signal correlation is where orchestration creates value that no single tool can generate on its own.

What Is a Signal?

A signal is an event with context. "Customer cancelled subscription" is an event. "Customer cancelled subscription after leaving a 2-star review yesterday and filing a support ticket that was resolved with a 'dissatisfied' rating three days ago" is a signal. The difference is cross-tool context.

The orchestration layer builds signals by correlating events across tools in real time. When a subscription cancellation event arrives from Recharge, the system immediately queries the identity graph to find that customer across all connected tools. It checks Yotpo for recent review activity. It checks Gorgias for recent support interactions. It checks Klaviyo for recent email engagement. It checks Smile.io for loyalty status and points balance.

Within milliseconds, a single cancellation event becomes a rich, cross-tool signal that tells the full story of why this customer is leaving and what the appropriate response should be.

Signal Correlation Engine

The correlation engine processes incoming events through a series of stages:

Stage 1: Identity Resolution. The incoming event is matched to the unified identity graph. The system identifies the customer across all connected tools.

Stage 2: Context Enrichment. The system queries connected tools for relevant context — recent interactions, current status, historical patterns. This happens via cached data where available and real-time API calls where needed.

Stage 3: Pattern Matching. The enriched signal is evaluated against known patterns. Is this a typical churn signal? A high-value customer at risk? A loyalty program candidate? A VIP who needs white-glove treatment? Pattern matching uses both rule-based logic (configurable by your team) and machine learning models trained on aggregated, anonymized behavioral patterns across the platform.

Stage 4: Action Determination. Based on the enriched signal and pattern match, the system determines the optimal coordinated action. This might be a single action in one tool (trigger a specific Klaviyo flow) or a coordinated multi-tool response (pause the Attentive SMS cadence, trigger a Klaviyo VIP win-back flow, flag the customer in Gorgias for priority support, and offer a loyalty points bonus in Smile.io — all within seconds of the cancellation event).

Stage 5: Conflict Resolution. Before executing, the system checks for conflicts. Is Klaviyo already mid-flow for this customer? Did Attentive send an SMS in the last hour? Is there a frequency cap that would be violated? Conflict resolution prevents the exact problem orchestration exists to solve: uncoordinated multi-tool noise.

Stage 6: Execution or Recommendation. Based on your permission configuration, the system either executes the determined actions automatically (if write access is granted) or surfaces them as recommendations for your team to approve (if running in read-only mode).

This entire pipeline runs in real time. From event ingestion to action execution, typical processing time is under 500 milliseconds for simple signals and under 2 seconds for complex multi-tool correlations.

---

Action Execution: The Read-Only / Write Permission Model

The permission model deserves its own section because it is the single most common area of concern in technical evaluations.

How Permissions Work

Permissions are configured per tool and per action category. Here is the granularity:

Read permissions are granted when you connect a tool. Connecting Klaviyo grants the orchestration layer read access to campaign data, flow data, subscriber data, and engagement metrics. Read permissions are all-or-nothing per tool — either the tool is connected (readable) or it is not.

Write permissions are opt-in per tool and per action type. For Klaviyo, write permission categories might include:

• Trigger a flow (separate permission)
• Add/remove subscribers from lists (separate permission)
• Create/modify segments (separate permission)
• Modify campaign content (separate permission — most teams never grant this)

You can grant "trigger a flow" permission without granting "modify campaign content" permission. You can grant write access to Klaviyo without granting write access to Recharge. Every permission is independent.

The Audit Trail

Every action the orchestration layer takes — read or write — is logged. The audit log captures:

• Timestamp
• Customer identifier (tool-specific ID, not PII)
• Tool targeted
• Action type
• Request payload (sanitized of PII)
• Response status
• Processing context (what signal triggered this action and why)

The audit trail is accessible in the Phleid dashboard and exportable via API. If your compliance team needs to know exactly what the orchestration layer did to a specific customer in a specific tool at a specific time, the data is there.

Escalation and Override

Not every action should be automated. The orchestration layer supports escalation rules — conditions under which the system surfaces a recommendation to a human instead of executing automatically.

Common escalation triggers include:

• Actions affecting customers above a configurable LTV threshold
• Actions that would modify subscription billing amounts
• Actions during a configurable "quiet period" around major promotions
• Any action type that your team has flagged as requiring human approval

Escalations are delivered via Slack (direct channel to the orchestration platform team), email, or in-dashboard notification. Your team reviews the recommendation, approves or modifies it, and the system executes the approved action. Over time, as confidence builds, teams typically move more action categories from escalation to automated execution.

---

Failure Modes: What Happens When Things Break

Every system fails. What matters is how it fails. Here are the specific failure scenarios a technical evaluator should understand.

Scenario 1: A Connected Tool's API Goes Down

Klaviyo's API becomes unavailable. What happens?

The orchestration layer detects the outage within seconds via failed health checks and elevated error rates. It takes the following actions:

1. Queues outbound actions. Any write actions destined for Klaviyo are placed in a durable queue with configurable retry logic (exponential backoff with jitter, maximum retry window of 24 hours).
2. Continues processing other tools. The orchestration layer does not stop. Events from all other tools continue to flow, be correlated, and trigger actions in non-affected tools.
3. Adjusts signal processing. The correlation engine marks Klaviyo data as potentially stale and adjusts confidence scores accordingly. It does not make decisions that depend critically on real-time Klaviyo data while the API is down.
4. Alerts your team. A notification is sent via your configured alert channel (Slack, email) indicating the outage, affected actions, and queue depth.
5. Replays queued actions on recovery. When Klaviyo's API recovers, queued actions are replayed in order. Deduplication logic prevents double-sends. Time-sensitive actions that have expired (e.g., a flash sale notification for a sale that ended during the outage) are discarded with a log entry.

The key principle: a single tool's outage does not cascade. The orchestration layer degrades gracefully, isolating the failure to the affected integration.

Scenario 2: API Rate Limiting

You have 28 tools connected. Each has API rate limits. Some are generous (Shopify allows thousands of calls per minute for Plus merchants). Some are restrictive. What happens when the orchestration layer hits a rate limit?

The system implements proactive rate management, not reactive rate handling. For each connected tool, the orchestration layer knows the rate limit tier, tracks current consumption against that limit, and throttles requests before hitting the ceiling.

In practice:

• Each integration module maintains a token bucket rate limiter calibrated to the tool's API limits.
• Requests are prioritized by urgency. Real-time event processing gets priority over historical data queries.
• When approaching a rate limit threshold (typically 80% of the allowed rate), the system reduces non-critical request frequency and queues lower-priority operations.
• If a rate limit is hit despite proactive management (e.g., because your own team's API usage consumed part of the quota), the system handles the 429 response, backs off per the tool's Retry-After header, and retries automatically.

You should never need to think about rate limits across your 28 tools. The orchestration layer manages this as a core infrastructure concern.

Scenario 3: The Orchestration Layer Itself Goes Down

This is the most important question: what happens if Phleid is unavailable?

The answer is straightforward: your tools continue working exactly as they did before you connected the orchestration layer. Klaviyo keeps sending emails. Attentive keeps sending SMS. Recharge keeps managing subscriptions. Gorgias keeps handling tickets.

The orchestration layer is an overlay, not a dependency. Your tools do not route through it. They are not configured to require it for basic operation. If the orchestration layer goes down, you lose the coordination intelligence — the cross-tool correlation, the unified signals, the automated multi-tool responses. You do not lose any tool functionality.

When the orchestration layer recovers, it catches up on missed events (via webhook replay and polling backfill), processes any queued actions, and resumes normal operation. There is no data loss and no manual recovery required.

This is an intentional architectural decision. An orchestration layer that becomes a single point of failure for your entire retention stack is worse than no orchestration at all. The overlay architecture ensures that the system adds value without adding risk.

Scenario 4: Stale Data or Conflicting Signals

What happens when two tools report conflicting information about the same customer? For example, Klaviyo shows the customer as "engaged" (opened an email yesterday) but Recharge shows them as "churning" (downgraded their subscription this morning).

The correlation engine handles this by design. Conflicting signals are not errors — they are information. A customer who is engaged with email but downgrading their subscription is telling you something specific: they like your content but have a product or pricing issue. The orchestration layer surfaces this as a compound signal with both components intact, enabling a response that addresses the specific situation rather than averaging two contradictory data points into meaninglessness.

When data staleness is the issue (e.g., one tool's data is current but another's is lagging due to polling interval), the system timestamps all signals and weights more recent data accordingly. Decisions that require freshness above a configurable threshold will trigger a real-time API call to the source tool rather than relying on cached data.

---

Security Model: No PII, Managed Keys, SOC 2

Security architecture for a platform that connects to 28+ tools holding customer data requires specific, verifiable commitments. Here is the security model.

No PII Storage

As detailed in the data model section, the orchestration layer does not persist customer PII. No names. No email addresses. No phone numbers. No payment data. No physical addresses.

The system processes PII transiently during signal correlation — it may read an email address from Klaviyo's API to resolve a cross-tool identity — but this data is held only in ephemeral memory during processing and is not written to persistent storage.

This dramatically reduces your data security exposure. A breach of the orchestration layer would not expose customer data because customer data is not there. An attacker who gained access to the orchestration layer's database would find identity mappings (tool-specific IDs), configuration data, and action logs — none of which contain exploitable customer information.

API Key Management

The orchestration layer stores API keys and authentication credentials for each connected tool. These are encrypted at rest using AES-256 and in transit using TLS 1.3. Key access is restricted to the integration service layer — no human at Phleid has access to your API keys in plain text.

API keys are scoped to the minimum permissions required for the configured integration. If you grant read-only access, the system stores a read-only API key. If you later grant write permissions, you provide a new key with appropriate scopes. The system does not request or store keys with broader permissions than what you have configured.

Key rotation is supported and recommended. You can rotate API keys for any connected tool at any time without service interruption — the system accepts the new key and begins using it for subsequent API calls.

SOC 2 Compliance

Phleid's SOC 2 Type II certification is in progress. This covers the five trust service criteria: security, availability, processing integrity, confidentiality, and privacy.

In practical terms, SOC 2 compliance means:

• Annual third-party audits of security controls
• Documented access controls and change management processes
• Incident response procedures with defined SLAs
• Regular penetration testing and vulnerability scanning
• Employee security training and background checks

Until the SOC 2 certification is complete, Phleid provides a detailed security questionnaire response and architecture documentation to any evaluating team. A direct Slack channel to the founding engineering team means your security questions get answered by the people who built the system, not a support ticketing queue.

Network Architecture

The orchestration layer runs on isolated cloud infrastructure with no shared tenancy. Your data processing does not share compute or memory resources with other customers. Network traffic between the orchestration layer and your tools traverses the public internet (the same path your tools' own integrations use) over encrypted TLS connections.

---

Implementation: Days, Not Months

The most common technical objection to a new platform is implementation time. Here is what implementation actually involves.

Day 1: Connect Your Tools

You provide API credentials for each tool you want to connect. The orchestration layer validates each connection, confirms API access levels, and begins ingesting events. For a stack of seven tools, this takes one to two hours.

No code changes. No Shopify theme modifications. No DNS changes. No webhook configurations on your end (the platform handles webhook registration where applicable). You are providing API keys, the same way you would connect any tool to any other tool.

Days 2-7: Signal Calibration

The orchestration layer spends the first week ingesting events and building its identity graph. It maps customer identifiers across tools, establishes baseline behavioral patterns, and begins generating cross-tool signals.

During this period, the system is fully read-only. It is observing, correlating, and learning. It surfaces insights and recommendations in the dashboard but takes no actions. Your team reviews the recommendations and provides feedback that calibrates the system's pattern matching.

Days 7-14: Recommendation Mode

The system begins generating actionable recommendations — specific, coordinated multi-tool actions it would take if write permissions were granted. Your team reviews these recommendations, approves or rejects them, and the system learns from these decisions.

This is the evaluation period. You are seeing exactly what the orchestration layer would do without any risk. If the recommendations are wrong, there is no cost — you simply correct them and the system adjusts.

Days 14-30: Selective Automation

Based on confidence built during recommendation mode, your team selectively grants write permissions for specific tools and action types. Most teams start with low-risk, high-frequency actions — triggering existing Klaviyo flows, adjusting Attentive SMS cadences, flagging customers in Gorgias for priority support.

Over the following weeks, as confidence grows and results validate the system's decisions, teams expand automation scope. There is no pressure to automate everything. Some teams run in recommendation mode for months on certain action categories. The system provides value at every point on the automation spectrum.

What You Do Not Need to Do

• Migrate data from any tool
• Replace any tool
• Modify your Shopify storefront
• Write custom integration code
• Train your team on a new email or SMS platform
• Change your existing workflows or automations (they keep running)
• Hire an implementation consultant

The total engineering investment for a typical implementation is two to four hours of initial configuration and two to three hours of review time during the first two weeks. This is not a six-month platform migration. This is connecting API keys and reviewing recommendations.

[link to Article 01: What Is Retention Orchestration]

---

Frequently Asked Questions

Does the orchestration layer create latency in my existing tools?

No. The orchestration layer does not sit in the request path of any of your tools. Klaviyo sends emails at the same speed whether the orchestration layer is connected or not. The layer receives events from your tools and sends actions to them, but it does not intercept or proxy any existing tool-to-tool communication. Your current stack performance is completely unaffected.

How does the orchestration layer handle data privacy regulations like GDPR and CCPA?

Because the orchestration layer does not store PII, it simplifies your compliance posture rather than complicating it. Customer data subject access requests (DSARs) and deletion requests are handled by your tools of record — the orchestration layer has no PII to produce or delete. The identity graph (cross-tool ID mappings) can be purged for any customer on request, and ephemeral signal data is cleared automatically during normal processing. Your DPA with Phleid covers the transient processing of data, and the platform's data processing architecture was designed with GDPR's data minimization principle as a primary constraint.

What happens to my orchestration rules if I switch one of my underlying tools?

Orchestration logic is defined at the capability level, not the tool level. If you switch from Attentive to Postscript for SMS, you disconnect one integration and connect another. Your orchestration rules reference "SMS channel" not "Attentive API endpoint." The new tool slots into the same role in your orchestration logic. Most tool swaps require less than an hour of reconfiguration, and the orchestration layer rebuilds its identity graph for the new tool within 24 hours.

Can I run the orchestration layer alongside my existing Zapier or custom integrations?

Yes. The orchestration layer does not require exclusive access to your tools' APIs. Your existing Zapier workflows, custom integrations, and native tool-to-tool connections continue to run. The orchestration layer coordinates at a higher level — it is not replacing your point-to-point integrations but adding a cross-tool intelligence layer on top of them. Over time, most teams find that many of their Zapier workflows become redundant as the orchestration layer handles the coordination natively, but there is no requirement to remove them.

---

{
  "seo_metadata": {
    "title": "What Is a Retention Orchestration Layer? Technical Architecture Overview | Phleid",
    "meta_description": "Technical deep dive into retention orchestration layer architecture: API-first design, event-driven processing, read-only defaults, 28+ integrations, failure modes, and security. For Marketing Ops and Engineering teams.",
    "primary_keyword": "retention orchestration platform",
    "secondary_keywords": [
      "marketing orchestration layer architecture",
      "retention orchestration layer",
      "API-first retention platform",
      "event-driven marketing architecture",
      "e-commerce marketing orchestration",
      "retention tool integration architecture",
      "read-only marketing platform"
    ],
    "target_word_count": "4500-5500",
    "actual_word_count": 4850,
    "internal_links": [
      "Article 01: What Is Retention Orchestration",
      "Article 09: DTC Martech Stack Optimization",
      "Article 15: Klaviyo + Attentive + Yotpo Integration"
    ],
    "external_links_suggested": [
      "SOC 2 Trust Service Criteria (AICPA)",
      "Shopify API rate limiting documentation",
      "Klaviyo API documentation"
    ],
    "schema_type": "TechArticle",
    "content_format": "Technical explainer",
    "target_persona": "Technical Validator (Marketing Ops Manager, Director of Engineering)",
    "search_intent": "Informational"
  }
}