Four integrations, named by their systems.
Each of these is a real shape of problem rather than an industry label. The mechanism is the same every time: declare the connection, map and validate the record, deliver it, and keep the execution history.
Customer data synchronization
Finance owns the customer record in the ERP; sales owns it in the CRM. Both edit it. Reconciliation happens in a spreadsheet, monthly, by hand.
DataBridge holds the contract between the two systems: which fields move in which direction, which side wins a conflict, and what happens to a record that satisfies neither.
- Bi-directional, cursor-based incremental sync on updated_at
- Conflict rule: last-write-wins per field, with an override list
- Idempotency on the external id, so a replay cannot duplicate
- Records missing a tax id are quarantined, not written
Stages used:ConnectTransformValidateRouteDeliver
Ecommerce data pipelines
Orders and inventory live in the storefront. Operations, finance and the internal dashboard each poll it directly, and each has its own idea of what an order line is.
One pipeline normalises orders once, writes them to the operational database, and publishes an event. Consumers read the normalised record instead of the storefront API.
- Five-minute schedule plus a webhook trigger on order.created
- Currency and unit normalisation at the transform stage
- Line-item flattening into a separate destination table
- Publishes order.synced for downstream applications
Stages used:ConnectTransformValidateRouteDeliver
Internal API enablement
Three teams need customer data. Each has been given credentials to the source system, so the source system now has three unmanaged consumers and no rate limiting.
The flow output becomes a generated read API with its own schema, keys and limits. No consumer touches the source system again.
- One /v1/customers endpoint over three upstream systems
- Schema generated from the validated output, not the source
- Per-consumer keys, scopes and rate limits
- Cursor pagination with a documented contract
Stages used:ConnectTransformValidateRouteDeliver
Operational data sync
An internal application needs data from four systems. Four scheduled scripts write into it; when one fails quietly, the application shows stale data and nobody knows which source is behind.
Four connections fan in to one destination with per-source mapping and precedence, and one run history that says exactly which source last wrote each field.
- Fan-in from four connections to one destination
- Per-source field mapping with precedence rules
- Separate run history and error rate per source
- Alert on a source that has not produced records in 2 cycles
Stages used:ConnectTransformValidateRouteDeliver
Whatever the systems are
The workflow does not change.
A CRM-to-database sync and an ERP-to-application fan-in are the same five steps against different connections. That is the point of having a layer.
# 1 · declare the connection (tested before it can be saved)POST /v1/connections { "type": "postgres", "environment": "production" } # 2 · create the flow and map the fieldsPOST /v1/flows { "name": "customer-sync", "source": "con_4b21" } # 3 · dry run against 50 records, writing nothingPOST /v1/flows/flw_2a19/run { "mode": "dry_run", "limit": 50 } # 4 · deploy version 1 and arm the schedulePOST /v1/flows/flw_2a19/deploy { "message": "initial customer sync" } # 5 · watch itGET /v1/runs?flow=flw_2a19&status=partialIllustrative. Endpoints are documented ahead of implementation.