The Canonical Data Model: One Hub to Rule Them All

If you've built integrations before, you've probably experienced the point-to-point problem. Need to sync Shopify with Linnworks? Build an integration. Add Magento? Build two more (Magento→Linnworks, Shopify→Magento). Add Amazon? Three more. The number of integrations grows as N×(N-1) — and maintenance becomes a nightmare.

The point-to-point problem

With 5 platforms, you need 20 point-to-point integrations. With 10, you need 90. With 30, you need 870. Each one has its own field mapping, error handling, and transformation logic.

This doesn't scale. Every new platform multiplies the maintenance burden.

The canonical solution

PullPush uses a canonical data model as the hub between all systems:

Shopify    → Canonical → Linnworks
Amazon     → Canonical → Magento  
Magento    → Canonical → Shopify
HubSpot    → Canonical → Tripletex

Each platform only needs one mapping — to/from canonical. Adding a new platform is O(1), not O(N). With 30 platforms, you need 30 mappings instead of 870.

What lives in the canonical model

PullPush defines canonical types for common e-commerce data:

Stock levels — the most critical. SKU, quantity, location, timestamp. The canonical model enforces the null-vs-zero distinction: null means "no data at this location" (skip), 0 means "genuinely out of stock" (update).

Orders — order ID, status, currency, total, line items, customer. Different platforms represent order status differently (Shopify uses strings, Linnworks uses numeric codes), but canonical normalizes them.

Products — SKU, title, description, price, variants. Product structure varies wildly between platforms (Shopify variants, Magento configurable products, WooCommerce variations), but canonical provides a consistent shape.

Recursive validation

Every canonical event is validated before entering the pipeline. validateCanonical recursively checks:

Required fields are present and non-null
Types match the schema (string, number, date)
Nested objects (like line items within orders) are individually validated
Custom validators run for domain-specific rules

Invalid events are rejected with a specific error — they never reach the destination.

The result

When a new connector is added (by AI, MCP, or manually), it immediately works with every existing destination. No additional mapping, no new integration code, no testing matrix explosion.

The canonical model is the foundation that makes PullPush's "self-growing marketplace" possible. Each new connector adds capability to the entire system, not just to one integration.