The layer between your systems and everything that reads them.
DataBridge Core is ten product areas around one engine. A record enters through a connection, is mapped and validated against rules you declare, and leaves as a destination write, a webhook or an API response — with every step recorded.
01
Business systems
CRM · ERP · databases · commerce · internal APIs
02
Connections
authenticated, tested, environment-scoped
03
Data flows
versioned, declarative pipelines
04
Transformation
mapping, typing, derivation, enrichment
05
Validation
required fields, types, rules, quarantine
06
Delivery
write, publish, expose
07
APIs · webhooks · applications · destinations
consumers never touch the source
One spine, everywhere
The five stages you configure are the five stages you watch.
The same order appears in the flow builder, the run timeline, the logs and this site.
Credentials are stored encrypted and scoped to an environment. Connections are tested before use and report health continuously.
POST /v1/connections/test → 200 {"status":"healthy","latency_ms":118}Credentials are stored encrypted and scoped to an environment. Connections are tested before use and report health continuously.
POST /v1/connections/test → 200 {"status":"healthy","latency_ms":118}DataBridge Core
Six areas you work in every day.
- 01 / ConnectionsAuthenticated system linksStore credentials encrypted, scope them per environment, test before use, and watch health continuously.→ /product/connections
- 02 / Data FlowsVersioned record pipelinesDeclare a pipeline from source to destination. Deploying publishes an immutable version you can roll back to.→ /product/data-flows
- 03 / TransformationsTyped mapping and validationMap fields explicitly with types, derive values from a function library, and reject bad records with a reason.→ /product/transformations
- 04 / Sync EngineScheduled and triggered executionCron, manual and webhook triggers with cursor-based incremental sync, retries and idempotent writes.→ /product/data-flows/#sync
- 05 / API GatewayRead APIs over synced recordsA REST endpoint generated from your flow output schema, with environment-scoped keys and rate limits.→ /product/api-gateway
- 06 / ObservabilityRuns, logs and metricsPer-record execution history, a structured log stream, throughput and error-rate metrics, and alert rules.→ /product/monitoring
- ConnectionsOne place that holds the credentials.Read
- Data FlowsPipelines you can version, test and roll back.Read
- TransformationsMapping that is declared, not scripted.Read
- API GatewayA read API over records you have already validated.Read
- WebhooksEvents that are signed, retried and replayable.Read
- MonitoringEvery record that moved, and every one that did not.Read
The workspace
What it looks like to operate.
Workspace
Overview
last 24 hours · production · sample data
Active connections
12
+2 vs prior
Active flows
28
+3 vs prior
API requests 24h
18,402req
+4.1% vs prior
Records processed 24h
184,291rec
+1.8% vs prior
Errors 24h
43
−12 vs prior
p95 latency
310ms
−24 vs prior
| Flow | Source → destination | Trigger | |||
|---|---|---|---|---|---|
| customer-syncv5 | CRM (sample) → PostgreSQL (sample) | cron 15m | Success | 14:02:11 | 14:17:11 |
| order-pipelinev11 | Commerce (sample) → PostgreSQL (sample) | webhook | Running | 14:04:02 | on event |
| inventory-reconcilev3 | ERP (sample) → Commerce (sample) | cron 1h | Partial | 13:30:00 | 14:30:00 |
| contact-enrichv2 | CRM (sample) → Internal API (sample) | cron 6h | Success | 12:00:04 | 18:00:00 |
| ledger-exportv7 | ERP (sample) → S3 (sample) | cron 24h | Queued | 02:00:00 | 02:00:00 |
- field_required43
inventory-reconcile · email required
quarantined13:32:41
- type_mismatch2
customer-sync · created_date not a timestamp
quarantined14:02:14
- upstream_timeout1
order-pipeline · read timed out after 30s
attempt 2/514:04:20
- run_8f21c9a4order-pipeline · 14:04:02
- run_8f21b7e0customer-sync · 14:02:11
- run_8f219c31inventory-reconcile · 13:30:00
- run_8f2188aacustomer-sync · 13:47:11
Interface fragments · sample data
Active connections
12
Active flows
28
API requests 24h
18,402
Records processed 24h
184,291
order-pipeline
Commerce (sample) → PostgreSQL (sample)
- Trigger
- webhook
- Version
- v11
- Last run
- 14:04:02
- Next run
- on event
run_8f21b7e0
customer-sync · v5 · cron
- Read4.1 s
- Transform2.2 s
- Validate1.4 s
- Write3.6 s
1,284 in · 1,282 out · 2 quarantined
Against adjacent approaches
What each approach leaves unsolved.
A comparison of mechanisms, not of named vendors.
| Approach | What it leaves unsolved | What DataBridge does |
|---|---|---|
| In-house point-to-point scripts | No shared observability; credentials scattered; every change is a deploy | Declared connections, versioned flows, one run history |
| Warehouse-first ELT | Data lands in analytics, not in operational systems or APIs | Delivery is operational: destination writes, webhooks, read APIs |
| General workflow automation | Task-shaped, not record-shaped; weak typing; opaque partial failures | Typed record pipelines, per-record status, quarantine and replay |
| An API gateway alone | Routes requests; does not reconcile or transform the underlying data | The gateway sits on top of synced, validated records |
Scope
What DataBridge is deliberately not.
Not an AI platform
The value is deterministic, auditable data movement. Non-determinism is a liability here.
Not a workflow automation tool
Automation tools are triggered by human events. DataBridge is triggered by system state and schedules, and is measured in records.
Not a CRM or a warehouse
DataBridge moves your customer data; it never owns it, and it does not become the system of record.