Capability 07 of 10 · One system, supported
Your tools, connected into one system, and engineers on call after launch.
Integration & Support connects your applications and data into one working system, then keeps it running with ongoing engineering: monitoring, incident response, upgrades and continuous improvement under agreed service levels.
Behind the heading, a transit-style map of a typical system estate: a storefront, payments, ERP, warehouse, CRM, support desk, email, analytics and a data warehouse, joined through one integration layer by an orders line, a customer line and a data line, with events moving along each line.
$ estate audit --hand-offs 30 tools · 15 manual hand-offs
Thirty tools, and people copying between them.
Most estates grow one sensible tool at a time. Together they leave people re-keying orders into the ERP, reconciling two customer lists by hand and trusting nightly CSV exports that fail without telling anyone.
A board of thirty business tools. Today, fifteen manual copy-and-paste hand-offs cross between them, through spreadsheets such as Orders.xlsx, Leads.csv and a stock sheet. Connected, one integration line calls at every system and the six spreadsheets and duplicate tools are retired.
- Re-keying per week across a 12-person operations team
- 4 h
down from 46 h - Customer records that disagree between CRM and ERP
- 0.2%
down from 7.1% - Nightly CSV jobs that failed last quarter without an alert
- 0
down from 9
Illustrative Figures for a typical mid-size retailer. The integration map in week two measures yours.
$ flow edit order-to-erp agent-assisted · schema-validated
Connect the fields. Catch the mistake before it ships.
A storefront order has to become an ERP sales order. Pick a source field, then the field it feeds, and choose a transform. Every change is validated against the ERP’s schema, so a wrong unit or format fails here, not at month-end.
Try it: map total_amount to amount with the transform set to Direct.
Interactive field mapper. Source fields from a storefront order event are listed first, then target fields of an ERP sales order. Select a source field and then a target field to connect them, choose a transform for each mapping, and review the validation results and the test delivery below. Auto-map proposes mappings with confidence scores for you to accept or reject. All data is fictional.
Flow complete. Select any source field to change a mapping.
SourceStorefront · order.createdwebhook payload
TargetERP · POST /v2/sales-ordersJSON Schema 2020-12
Mappings10 of 10 targets
-
idexternal_refyou -
created_atorder_dateyou -
customer.emailcustomer_idyou -
customer.first_namecustomer_nameyou -
total_amountamountyou -
currencycurrency_codeyou -
financial_statusorder_statusyou -
line_items[0].skulines[].item_codeyou -
line_items[0].quantitylines[].quantityyou -
shipping_address.cityship_to.cityyou
Mapping agent proposed 0 mappings from field names, sample values and the ERP schema. Nothing is applied until you accept it.
Previewsales_order.json
- {
- "external_ref": "ord_8F2K41",
- "order_date": "2026-09-14T16:17:03Z",
- "customer_id": "C-104233",
- "customer_name": "Asha Rao",
- "amount": 2499.00,
- "currency_code": "INR",
- "order_status": "INVOICED",
- "lines": [ {
- "item_code": "MUG-340-BLU",
- "quantity": 2
- } ],
- "ship_to": { "city": "Pune" }
- }
Validation8 / 8 required · 0 errors
external_refstringorder_datedate-time · UTCcustomer_idmatches ^C-\d{6}$customer_namestring · ≤ 80amountmatches order lines · 2 × 1,249.50currency_codeISO 4217order_statusenumlines[].item_codestringlines[].quantityinteger ≥ 1ship_to.citystring
Test deliverysandbox
POST /v2/sales-orders Idempotency-Key: order.created:ord_8F2K41:r1 Authorization: Bearer •••• (scope sales_orders:write)
201 Created184 ms
{ "id": "SO-2026-004187", "status": "INVOICED" }
Created once. Sending the same event again replays this result instead of creating a second order.
Fictional data Every delivery carries an idempotency key, so retries with exponential backoff and jitter can never create a second order. Events that still fail after the retry budget are parked in a dead-letter queue with their validation errors attached, ready to replay once fixed.
$ pattern choose --per-flow four patterns · one monitoring stack
The right pattern for each connection.
Not every flow should be an event, and not every sync needs a platform. We choose per connection, on latency, volume, data ownership and what must happen when the other side is down.
- 200 GET /v1/stock/MUG-340-BLU · 212 ms
- 504 ERP timeout after 800 ms · retry 1 in 180 ms (backoff + jitter)
- 200 retry 1 succeeded · 246 ms · total 1.23 s
Request–response
A caller sends a request and waits for the answer, over REST or GraphQL through a gateway that handles authentication, quotas and rate limits.
Use it when
- A person is waiting: stock at checkout, a price, an account lookup.
- The other system must confirm before the next step runs.
- Volumes sit comfortably inside the provider’s rate limits.
When it fails
- Every call has a timeout shorter than the caller’s own deadline.
- Retries use exponential backoff with jitter, and only for idempotent requests or with an idempotency key.
- A circuit breaker opens after repeated failures and serves a cached answer; 429s honour Retry-After.
- Kong
- GraphQL
- OpenAPI Initiative
- Postman
- pub order.created ord_8F2K41 · written with the order, relayed from the outbox
- dlq CRM sync failed 5 attempts · 12 events parked with errors
- replay 12 events replayed after fix · 0 duplicates (idempotent consumer)
Event-driven
The storefront publishes what happened; every system that cares subscribes. Producers never wait for, or even know about, their consumers.
Use it when
- Several systems react to the same business event.
- Bursts must be absorbed without losing an order.
- A slow or failing consumer must not stop the others.
When it fails
- Transactional outbox: the event is written in the same database transaction as the order, then relayed.
- At-least-once delivery into idempotent consumers, so a redelivery changes nothing.
- A schema registry rejects incompatible changes; poison messages move to a dead-letter queue and replay once fixed.
- Apache Kafka
- RabbitMQ
- Amazon EventBridge
- Azure Service Bus
- u customers id=42 · tier silver → gold · LSN 0/16B37C8
- sink warehouse 1.4 s · search 0.6 s · cache key customer:42 dropped
- load source queries added by capture: 0
Change data capture
Every committed change is read from the database’s own log and streamed on, so downstream systems stay current in seconds without anyone querying the source.
Use it when
- A legacy or vendor database has no usable API or events.
- Analytics and search must be fresh in seconds, not overnight.
- Polling queries are already loading the production database.
When it fails
- Reads the log (PostgreSQL WAL, MySQL binlog), so the source sees no extra query load.
- An initial snapshot, then streaming from a recorded log position; restarts resume without gaps.
- Replication slot size is monitored, so a stalled connector alerts before disk fills.
- Debezium
- Apache Kafka
- PostgreSQL
- Snowflake
- Elasticsearch
- #4811 5 steps · 1.8 s · succeeded
- #4812 create ticket 503 · retried in 30 s · succeeded
- #4813 new contact · lead created · 1.1 s
iPaaS workflow
Managed connectors and a visual workflow for the flows that change often and do not need custom code, run under the same monitoring and change control as everything else.
Use it when
- Standard connectors cover the systems involved.
- Volumes are moderate and operations teams want to adjust flows.
- Time to the first working flow matters more than cost per run at scale.
When it fails
- Step retries with limits, then an error workflow alerts a named owner with the failed run.
- Flows exported to version control and promoted between environments.
- Run history, alerts and dashboards alongside the custom integrations.
- n8n
- Zapier
- Make
- MuleSoft
- Boomi
Technologies we work with, chosen per flow. No partner status is implied.
Let’s build what happens next.
Tell us what you’re building. We’ll answer straight.