Pre-built Connectors
Maintained, ready-to-configure integrations for common SaaS platforms — no custom code required to onboard a new standard source or destination.
High-Level Design
Pre-built connectors turn a multi-week integration into a configuration task.
💼 Business Context
- Cuts integration time from weeks of engineering to hours of configuration for the ~80% of sources/destinations that are common SaaS platforms
- Centralizes connector maintenance so platform upgrades (e.g., a Salesforce API version bump) happen once, not per-integration
- Owned by Platform Engineering; connector roadmap is prioritized by business demand
🔌 Technical Overview
Each pre-built connector is a .NET Core microservice implementing a shared IConnector interface (auth, extract/webhook handling, field mapping, error handling) and calling Cxos.Ingestion.Client for outbound events or the Activation API's equivalent for Reverse ETL. Connectors ship as their own NuGet packages (Cxos.Connectors.*) so they can be versioned and deployed independently, and are registered centrally so any team can enable one via configuration rather than a deployment.
Example Connectors
💾 Connector Registration
{
"connector": "Cxos.Connectors.Salesforce",
"version": "2.4.0",
"instance_id": "sfdc_prod",
"auth": { "type": "oauth2_jwt", "keyvault_ref": "sfdc-prod-cert" },
"sync_mode": "cdc"
}
🔗 Integration Points
- Shared IConnector interface — every pre-built connector implements the same contract
- Cxos.Connectors.* NuGet packages — independently versioned per platform
- Azure Key Vault — per-instance credential storage
- Central connector registry — enables/configures instances without a new deployment
🧰 Services Consumed
- Owning microservice —
Cxos.Connectors.* (registry family)(see the Full Application Service Map) - No dedicated database — stateless connector (see Platform Connectors above)
⚠️ Non-Functional Considerations
- Scale: each connector instance runs and scales independently, so one integration's load never affects another's
- Latency: varies by connector — webhook-based connectors are near-real-time, polling-based connectors follow their configured interval
- Reliability: connector health/failure is monitored centrally, with automatic alerting to the owning team on sustained failure
- Security/Privacy: connector credentials are never stored in application config — always Key Vault references resolved at runtime
🎯 Enterprise Example
A new marketing team wants HubSpot data in CXOS. Instead of a new engineering project, they request the existing HubSpot connector be enabled for their instance, provide OAuth credentials through a secure onboarding flow, and see data flowing within the same day.