Capability 07 of 10 · Technology & Intelligence
We connect your CRM, ERP, commerce and payment systems through APIs and events, so data moves without re-keying. Then our engineers look after the integrations under agreed service levels: monitoring, incident response, upgrades and improvements.
Behind the heading, a transit-style map of a typical company’s systems: storefront, payments, ERP, warehouse, CRM, support desk, email, analytics and a data warehouse. An orders line, a customer line and a data line join them through one integration layer, with events moving along each line.
$ systems audit --hand-offs 30 tools · 15 manual hand-offs
Tools added one at a time leave staff re-keying orders into the ERP, reconciling customer lists by hand and relying on nightly CSV exports that fail silently.
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.
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
Map a storefront order to an ERP sales order by picking fields and transforms, or let an agent propose them. Every change is checked against the ERP’s schema and agent proposals wait for your approval.
Try it: set the transform on total_amount → amount to Direct, and watch the validation fail.
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, then a target field to connect them, choose a transform for each mapping and review the validation results and 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
id
external_ref
you
created_at
order_date
you
customer.email
customer_id
you
customer.first_name
customer_name
you
total_amount
amount
you
currency
currency_code
you
financial_status
order_status
you
line_items[0].sku
lines[].item_code
you
line_items[0].quantity
lines[].quantity
you
shipping_address.city
ship_to.city
you
Mapping agent proposed 0 mappings from field names, sample values and the ERP schema. Nothing is applied until you accept it.
Previewsales_order.json
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.citystringTest 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 a retry cannot create a second order. Events that still fail are held in a dead-letter queue with their errors attached, ready to replay once fixed.
$ pattern choose --per-flow four patterns · one monitoring stack
The choice depends on response time, volume, data ownership and what must happen when the other system is down. All four run under the same monitoring.
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
When it fails
The storefront publishes what happened and every system that needs it subscribes. Publishers never wait for their consumers.
Use it when
When it fails
Each saved change is read from the database’s own log and streamed on, so other systems stay current within seconds without querying the source.
Use it when
When it fails
Managed connectors and visual workflows for flows that change often and need no custom code, under the same monitoring and change control as everything else.
Use it when
When it fails
Technologies we work with, chosen per flow. No partner status is implied.
$ connectors search 31 systems · 9 categories
Find a system to see what syncs, how and what to watch out for. If yours is not listed, we build against any documented API, or against the database where there is none.
No connector matches . We build against any documented API, and connect databases without one through change data capture. Ask about your system.
Commerce · connector sheet
What typically syncs
How
Watch out for
Webhooks can arrive more than once or out of order. Each one is verified by its HMAC signature and de-duplicated by ID, and a reconciliation sweep catches any that never arrived.
Technologies we work with, shown with their own marks where the licence allows and a category icon where it does not. No partnership, certification or reseller status is implied. Vendor limits change; each connector is checked against current documentation when it is built.
$ spec diff --against published contract-first · versioned
Both sides of each integration test against one written contract, so a breaking change fails the build before it reaches your customers.
Illustrative pipeline · fictional API
@@ components.schemas.Order @@
required:
- id
- order_date
- customer_email
- customer_id
- amount
properties:
customer_email: { type: string, format: email }
customer_id: { type: string, pattern: "^C-\d{6}$" }
amount: { type: number, minimum: 0 }
Removing a required property is a breaking change. It is released as a new major version, and v1 keeps the old field through an agreed deprecation window.
Deprecation window, written into the change
Spectral rules: operation ids, error shapes, pagination, examples present.
46 rules · 0 errors
The new spec is compared with the published one. Removing a required property is breaking.
1 breaking · order.customer_email removed
Every registered consumer replays its recorded expectations against the new spec.
2 of 3 consumers fail
Breaking change accepted behind a major version, with the old field kept for one window.
v2.0.0 proposed · needs sign-off
The spec, the changelog and the generated clients are published; consumers are notified.
v2.0.0 published · 3 consumers notified
Credentials live in a managed secret store with rotation and scoped access, never in code, CI variables or a connector’s notes field.
Each integration gets its own client with the narrowest scopes that work, so a leaked token cannot read the whole tenant.
We honour the other side’s limits with exponential backoff and jitter, and publish our own so consumers can plan for them.
Consumer-driven contract tests are recorded by the teams that call the API and replayed on every change to it.
Specifications every integration is written against
Frameworks we align integration delivery with
The pipeline shown is illustrative: a contract check on a fictional orders API detects that a required field was removed and lists the two of three registered consumers that would break. It resolves as a new major version with a deprecation window.
$ oncall page --sev 2 On-call support
Alerts track what your customers notice. An agent groups the errors and drafts the first status note; the engineer checks it and makes every change to production.
Illustrative incident · fictional systems
INC-2026-0143 · severity 2
Resolved · 41 minutes
Orders have failed to reach the ERP for four minutes. The queue passes its threshold and pages the on-call engineer immediately.
orders.erp.dlq · depth 52 · rising
The agent reads the traces, finds that every failure shares one error, links the matching runbook and drafts the first status note. It deploys nothing.
HTTP 400 · "material_code not found" · 52 of 52 · runbook RB-014
The engineer confirms the cause: a new storefront product has no ERP material code. They correct the agent’s draft and send it.
MTTA 3 min · status page updated
Products without an ERP code now wait in a holding queue with the reason attached, instead of failing the whole batch.
PR #1182 · deployed · behind a flag · queue steady at 63
The 63 held messages are replayed in order. Idempotency keys stop partly processed ones from creating duplicate orders.
63 replayed · 0 duplicates · depth 0
Written within two working days, blameless, with every action owned and dated. This review added the daily check for products missing an ERP code.
PIR-2026-014 · 3 actions · 3 closed
The agent drafts, groups and links; the engineer decides. Every action, the agent’s included, goes to an audit log with its inputs, so the review works from the same record as everyone else.
orders.erp.dlq · depth
0 now · peak 63
03:07replay03:52
3min
Alert to a named engineer responding
41min
Alert to the queue back at zero
0
Idempotency keys on every replay
63
Dead-letter queue, replayed in order
03:52IST
Our on-call engineer
23:22BST
Your team, asleep
On-call coverage, its hours and the severity definitions behind these figures are set in each support agreement. The clocks show why every hand-off is written down.
Monitoring and on-call tools we run integrations on
An illustrative incident timeline: a dead-letter queue alert at 03:11 when depth passes fifty, an AI agent grouping the identical errors against a runbook, an engineer acknowledging in three minutes, a fix deployed, the queue replayed with no duplicates and a post-incident review with three closed actions. The chart beside it shows queue depth passing fifty at 03:11, peaking at 63 and returning to zero after the replay.
$ sla show --plans 3 plans · P1–P4
Three plans, from business hours to round the clock. Each sets response and restore targets by severity and includes monthly engineering hours for improvements.
P1Critical
A live integration is down or moving wrong data. There is no workaround and the business stops.
Orders stop reaching the ERP. Payments captured but not recorded.
P2High
A flow is degraded, delayed or partly failing, and someone is working around it by hand.
The nightly stock sync fails for one warehouse. Support tickets sync late.
P3Medium
A contained fault with limited impact: single records, one connector or a non-blocking error in the log.
One customer record will not map. A retry storm fills the log with noise.
P4Low
A question, a small change or a planned enhancement, scheduled into the monthly engineering hours.
Add a field to an existing mapping. Change an alert threshold.
Highlight a plan
| Commitment | Essential Business hours, with monitoring and patching. | Business Extended hours with paging on P1. | Critical Round the clock, with an engineer on call. |
|---|---|---|---|
| Response | |||
| P1 · first response A named engineer acknowledges it in person. | 4 business hours | 1 hour | 30 minutes |
| P1 · restore or workaround Service restored, or a workaround agreed in writing. | Next business day | 8 business hours | 4 hours |
| P2 · first response Triaged, owner assigned, impact confirmed. | 1 business day | 4 business hours | 1 hour |
| P2 · restore target Flow returned to normal throughput. | 3 business days | 2 business days | 8 hours |
| P3 · first response Logged, reproduced and added to the backlog. | 2 business days | 1 business day | 1 business day |
| P4 · first response Answered, or scheduled into the monthly engineering hours. | 5 business days | 3 business days | 2 business days |
| Coverage | |||
| Coverage window When the response clock is running. | Mon–Fri · 09:00–18:00 IST | Mon–Sat · 08:00–22:00 IST | 24×7, every day |
| Out-of-hours paging Which severities wake someone up. | Not included | P1 only | P1 and P2 |
| Named incident lead One person owns communication during a P1. | Not included | Included | Included |
| Included | |||
| Engineering hours each month Enhancements, upgrades and small features, prioritised with you. | 8 hours | 24 hours | 60 hours |
| Monitoring, patching & dependency upgrades Alerting, security patches and library upgrades on the integrations we run. | Included | Included | Included |
| Service review Service-level report, incident review and the improvement backlog. | Monthly report | Monthly call | Monthly call + quarterly roadmap |
Service management practice
Severity levels and incident, problem and change management use ITIL 4 terms, matching the language your IT team already uses. Delivery is measured with DORA metrics.
Frameworks we align support delivery with.
$ estate consolidate --dry-run 5 measures · one estate
A job that polls every five minutes runs 288 times a day, whether or not anything changed. We replace polling with events and retire tools that only move data.
After: connectors consolidated onto one event bus, polling replaced where the vendor supports it.
SaaS licences in the estate
Three tools existed only to move data between two others. Retiring them removes the seat cost and the integration surface at once.
26 seats
was 34
Scheduled polling jobs
Most polls asked "has anything changed?" every five minutes and were told no. Webhooks and change data capture replaced them.
6 jobs
was 41
Integration compute
Idle polling workers ran around the clock. Event consumers scale to zero between messages.
430 hours / month
was 1,240
Estimated energy
Derived from compute hours and the published carbon intensity of the region, not measured at the socket.
178 kWh / month
was 512
API calls to vendor systems
Fewer calls also means fewer rate-limit incidents and lower tiered API charges.
0.4 million / month
was 11.8
Each is an ordinary integration decision that also cuts energy use, licence cost and rate-limit incidents.
01
Where a vendor supports webhooks, updates arrive only when data changes. Otherwise, change data capture reads the database log instead of re-reading whole tables.
poll every 5 min webhook or CDC on change
02
Full reconciliation runs once a night in a region and a window with lower carbon intensity, instead of hourly all day.
reconcile hourly, all day one nightly low-intensity window
03
Point-to-point connector subscriptions can be cancelled once the flows run on one event bus you already operate.
3 point-to-point tools 1 bus you already run
04
Filtering fields and compressing at the source cut payload size; batching cuts request count without delaying time-critical flows.
whole record, every time changed fields, batched
The panel compares one illustrative estate before and after consolidation: 34 SaaS licences fall to 26, 41 scheduled polling jobs fall to 6, integration compute falls from 1,240 to 430 hours a month, estimated energy from 512 to 178 kWh a month and vendor API calls from 11.8 million to 0.4 million a month.
$ run phase --next 4 phases · from mapping to support
Each integration is monitored from the day it goes live, so the team supporting it already knows its history.
Typical phase lengths
Phase 01 / 04 Wk 01–02
We map systems, data flows, owners, volumes and failure points, then agree a pattern and contract per flow.
The phase is complete when
Every flow in scope has one named owner on your side and an agreed pattern on ours, signed off in writing.
What you keep
3Who is involved
Where this phase usually slips
Ownership. Two teams each believe they hold the customer record, and no flow can be built until they agree which copy is correct.
Phase 02 / 04 Wk 02–08
We build each flow with retries, duplicate protection and alerts, then test it against sandboxes and recorded traffic.
The phase is complete when
Each flow passes its contract tests against the vendor sandbox and survives a deliberate failure with no data lost.
What you keep
3Who is involved
Where this phase usually slips
Sandboxes. A vendor sandbox can behave differently from production, so every flow is also replayed against recorded production traffic.
Phase 03 / 04 Wk 08–10
We agree runbooks, access, monitoring and support tiers, then rehearse an incident with your team.
The phase is complete when
Your team and ours rehearse one full incident using the production runbook and alert.
What you keep
3Who is involved
Where this phase usually slips
The rota. Paging a shared mailbox is not on-call cover, so this phase stays open until a named person receives the alert.
Phase 04 / 04 Ongoing
We run on-call, incidents, upgrades and improvements, with a monthly SLA review and a quarterly roadmap.
The phase is complete when
It does not close. Support is reviewed every month against the same measures.
What you keep
3Who is involved
Where this phase usually slips
Silence. A quarter with no reported incidents usually means the monitoring has gaps.
Support starts in phase three, so nothing is handed over at the end. The engineers who built each flow answer its alerts.
The four phases in order: Map (Wk 01–02), Connect (Wk 02–08), Transition (Wk 08–10), Support (Ongoing). Each panel below the line lists what the phase decides, what it needs from you, when it is complete, what you keep, who is involved and where it usually slips.
$ ls artefacts/ 7 artefacts · in your repositories and accounts
Maps, specifications, code, tests, runbooks and reports that let your team, a new vendor or whoever is on call understand and run your integrations.
01
Every system and flow, the source of truth for each field and its owner. The first document a new engineer reads.
Diagrams
02
OpenAPI 3.1 and AsyncAPI definitions in your repository, published to a portal your own teams and vendors can read.
OpenAPI · portal
03
The connectors in your source control, with dashboards and alert rules stored beside the code.
Code · iPaaS · alerts
04
Consumer-driven contract tests that run in CI, so a vendor schema change fails a pipeline instead of a customer order.
Tests · CI
05
Severity definitions, response and restore targets, escalation path and named contacts, agreed before go-live.
Agreement
06
One page per failure mode: what the alert means, how to confirm it, how to fix it and when to escalate.
Docs · rota
07
Sync success, data freshness, incidents, what we changed and the improvement backlog for the month ahead.
Report
What we make for you is yours once it is paid for. Tools we already had stay ours, and you get a free, permanent licence to use them.
Connector code, infrastructure definitions, tests and alert rules go into repositories you own from the first week.
Vendor keys and OAuth clients are issued in your accounts. Our access is scoped, and you can revoke it in one step.
Runbooks, decision records and the integration map are updated as the integrations change, so another team can take over support.
$ report service --period 30d same seven measures, every month
Every monthly service review reports these seven measures, each with its definition and data source, so the report keeps the same shape each month.
01
Events accepted by the target system as a share of all events published, measured at the consumer after retries.
Read from Consumer acknowledgements · OpenTelemetry
Typical at handover
96.4%
Target
99.9%
96% of the way to target by the third review
02
Time from a change in the source system to its arrival in the target, at the 95th percentile for the month.
Read from Event timestamps compared at both ends
Nightly batch
6 h
Target
5 min
74% of the way to target by the third review
03
Failed events still waiting after all retries, counted at the end of each day. Anything older than 24 hours is escalated.
Read from Queue depth, with an end-of-day alert
Before monitoring
180
Target
0
88% of the way to target by the third review
04
Records re-typed or copied by hand each week that an integration now handles.
Read from Counted with your team in the integration inventory
At the start
0
After phase two
400
62% of the way to target by the third review
05
Average time from an alert to a named engineer acknowledging it, for P1 incidents only.
Read from On-call tooling · incident log
Unmonitored estate
42 min
Target
15 min
55% of the way to target by the third review
06
Average time from an alert to service being restored for users, for P1 incidents only. The root cause may be fixed later.
Read from Incident log · DORA metrics
Unmonitored estate
7 h
Target
2 h
70% of the way to target by the third review
07
Subscriptions that only moved data between two other systems, cancelled once the flows run on infrastructure you already operate. Polling jobs are counted separately.
Read from Your licence register · scheduler inventory
At the start
0
Year one
8
45% of the way to target by the third review
Starting points are typical of an estate with no monitoring and show the shape of the change, not a promise about yours. The progress figure is where a typical estate sits by the third monthly review. Targets are set per integration during onboarding, written into the support agreement and reviewed if traffic changes.
Seven measures are reported each month: sync success rate, targeted at 99.9 per cent; data freshness at the 95th percentile, from a nightly batch to five minutes; dead-letter queue depth to zero; manual steps removed, around four hundred a week after the second phase; time to acknowledge a P1 alert, targeted at fifteen minutes; time to restore, targeted at two hours; and redundant SaaS licences retired in the first year. Each row also shows how far a typical estate has moved towards its target by the third monthly review. All figures are illustrative.
Services & packages
We connect your applications so data is entered once and matches in every system. Engineers who know your set-up then support it, from monitoring and fixes to upgrades.
How to buy
How we work with you
Ask a quick question, send a project brief or issue a formal RFQ. The lead for the work reads each one in full, and any services already in your brief go with it.
Or book a thirty-minute call01
For a first conversation, a press request or anything that does not need a scope yet.
You get A reply from a named lead
02Recommended
Goals, audiences, a budget band and timing, so our first reply can outline the work.
You get Options and a first scope after one call
03
Your documents, deadlines and the procurement and security rules the work must meet.
You get Receipt confirmed and a named bid lead
How it is priced
Each package shows its pricing model. Work starts once a written scope and quote are agreed.
Opens a project brief with this package chosen.
In your brief
In your brief
In your brief
In your brief
| Package | Every engagement includes | Best for |
|---|---|---|
| ProjectA defined scope, delivered for a fixed price. |
|
Work you can describe up front: an identity, a platform or a set of tools |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Live brands and products that need a steady team without hiring one |
| MilestoneA larger build in phases you approve and pay for one at a time. |
|
Programmes too large for one contract, where you want control at each step |
| EnterpriseA multi-workstream programme with a dedicated team, governance and agreed service levels. |
|
Large organisations running change across markets, portfolios or business units |
$ ask --plainly seven common questions
Seven questions teams ask before starting an integration programme. If yours is missing, add it to your brief and we will answer in writing before we discuss price.
You can use both, chosen per flow under the same monitoring. iPaaS suits standard connectors, moderate volumes and teams who edit flows themselves. Custom code suits high volumes, complex transformations, strict latency or high per-run costs.
Support is agreed per system, typically with response targets by severity, business-hours or extended coverage, and a monthly improvement allowance. The exact terms are set in the support agreement.
Yes, after we assess the code, infrastructure, monitoring and documentation. We fix the gaps first, so support targets are realistic.
On-call engineers respond within set times per severity. A named incident lead updates your stakeholders, and a blameless review tracks actions to closure.
It covers monitoring, incident response, security patches and dependency upgrades. It also includes agreed engineering hours each month for improvements, prioritised with you.
A failing test flags it, so we migrate within the vendor’s notice period. We track changelogs and deprecation notices for every connector we run, and contract tests run against vendor sandboxes in CI. If a vendor gives no notice, failed messages wait in the dead-letter queue and replay once the fix is live, so nothing is lost.
Yes, with the notice period set in your contract. Support runs on a rolling term, and connectors, infrastructure definitions, tests, dashboards and runbooks sit in your repositories throughout. Credentials stay in your vault, so handover is a planned piece of work.
You will speak to a lead who would run the work, and get a straight answer on fit.
Three ways to start
Every engagement starts with a written scope and a quote agreed before work begins.
Choose one of the three ways above
