Third-Party and SaaS Integration Questions

Design
I would insert an anti-corruption layer between the vendor and the rest of the stack. That means the integration layer translates vendor payloads into a stable internal contract, and the downstream systems only see the internal shape.

Components

• Vendor adapter for each API or webhook version
• Canonical schema with versioning
• Transformer service that maps vendor fields to internal fields
• Contract tests that verify each adapter against sample payloads
• Replay pipeline so old events can be reprocessed through the new adapter

Example
If the vendor changes email_address to primary_email, only the adapter changes. Downstream systems still receive email. If the vendor adds a new field, I can ignore it until a consumer needs it, which avoids a cascade of changes.

How this prevents repeat pain
I would document field ownership, use schema validation at the edge, and run a parallel test environment before cutover. Then when the next vendor change arrives, the blast radius stays inside one adapter instead of spreading across every consumer.

Recommendation
For unsubscribes, I would centralize the consent workflow and let other systems react to the resulting event. This is a case where correctness matters more than loose independence, because one missed suppression can create a compliance problem.

How I would decide

• Centralize if there is one business rule for consent, one audit trail, and a hard deadline before the next send.
• Use choreography only when systems are loosely coupled and temporary delay is acceptable.

Failure modes I would watch

• A service misses the unsubscribe event
• A retry causes duplicate updates
• A campaign send races ahead of the suppression update
• One system updates from stale cache while another is current

Example
If a user opts out at 9:10 and a campaign is scheduled for 9:15, the central consent service should record the change immediately, publish an event, and block sends until all critical destinations confirm receipt or until the campaign filter reads from the central source of truth.

Control plane
I would add retries, dead-letter handling, a reconciliation job, and a pre-send suppression check so the system stays safe even if one downstream service is slow.

Design
I would use a canonical model, which is one shared internal schema that every system maps to. A mapping layer then converts each vendor's field names into that shared shape, so downstream consumers do not need custom logic for every source.

Structure

• Source adapter: CRM, ad platform, analytics tool, or support system
• Canonical customer event: normalized fields like customer_id, email, consent_status, event_time
• Destination adapter: writes to a specific tool in that tool's preferred format
• Mapping catalog: versioned rules that describe field equivalence and transformations

Example
The CRM might send first_name and last_name, the ad platform might send full_name, and analytics may only know anon_id. All three can map into a canonical profile with given_name, family_name, and anonymous_id. A downstream consumer reads only the canonical model, not three different vendor schemas.

Why this works
This keeps vendor churn isolated to adapters, makes validation easier, and gives you one place to handle defaults, type checks, and null rules. If a vendor changes a field name later, only that adapter changes.

Approach
I would do simple, time-sensitive work as early as possible and do profile-dependent enrichment later. Early pipeline stages should standardize fields, validate types, and route events. Later stages can join richer customer data once it is available.

Rule of thumb

• Early: parsing, normalization, dedup keys, basic filtering, and routing to the warehouse or operational tools
• Later: segmentation, lifetime value, behavioral scoring, and joins that depend on a complete customer profile

Example
An event arrives with country_code=us and signup_date=2025-07-01. I would normalize US immediately and send it to the warehouse and alerting tools within minutes. But if campaign targeting depends on a profile built from 20 past events, I would defer that enrichment until the profile store is updated.

Risks

• Doing too much early can lock in incomplete data and create wrong downstream actions
• Doing too much late can add latency and make operational tools stale

Balanced design
I would keep a raw immutable event store, a standardized stream for near-real-time actions, and a richer modeled layer for analytics. That gives both freshness and accuracy.

Decision factors
I would compare three options against four needs: speed to launch, complexity, maintainability, and latency. A native connector is simplest when the CRM and marketing tool already support the fields and schedule you need. An integration platform is good when you want faster setup, monitoring, and moderate customization. A custom API integration fits when rules are unique, scale is high, or data freshness matters.

Example
If the team only needs a nightly sync of name, email, and campaign status, a native connector is usually enough. If they later need updates within 5 minutes when a lead converts, I would move toward an API-based or event-driven design, because batch sync may be too slow.

My rule
Start with the least complex option that still meets the business need. If near-real-time updates become required, I would favor a design with webhooks or APIs plus retries and monitoring, because it gives better control over freshness and failure handling than a purely batch connector.