SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 02 · BuildSystem integrations & APIs
When people are the integration
Someone exports a file every morning and imports it somewhere else. That is an integration — it is just running on a person, and it fails quietly when they are on leave.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Agree the contractIn scope
- C02Check the data firstIn scope
- C03Make writes idempotentIn scope
- C04Design the failure pathIn scope
- C05Reconcile continuouslyIn scope
- C06Monitor as a business processIn scope
In short
A system integration moves data between two systems that were not designed to talk, so that people stop being the transport layer. Done properly it is not just a connection: it needs a defined contract between the systems, idempotent writes so a retry cannot duplicate an order, reconciliation to prove both sides agree, and a path for the records that fail validation. Most integration projects that disappoint were scoped as the happy path only.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistSystem integrations & APIs
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
Agree the contract
What moves, in which direction, how often, and which system is authoritative when they disagree. Most integration pain is an unresolved answer to that last question.
- 02
Step 2 of 6
Check the data first
Identifiers rarely match across systems as cleanly as anyone expects. The mismatch is found and quantified before build, because it determines the shape of everything after it.
- 03
Step 3 of 6
Make writes idempotent
A retry must not create a second order. This is designed in rather than patched after the first duplicate reaches a customer.
- 04
Step 4 of 6
Design the failure path
What happens when the far end is down, slow, or returns something unexpected. Records that cannot be processed go somewhere a person can see and act on.
- 05
Step 5 of 6
Reconcile continuously
A daily check that both sides agree, with the difference reported. An integration nobody is checking is an integration nobody knows is broken.
- 06
Step 6 of 6
Monitor as a business process
Alerting on throughput and error rate, not just on whether the service is running.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsSystem integrations & APIs
- 01
We will not: Build a real-time integration where a scheduled batch would be cheaper and easier to reason about.
- 02
We will not: Integrate two systems when the honest answer is to retire one of them.
- 03
We will not: Ship without reconciliation, because the demo looked correct.
- 04
We will not: Hide integration failures from the people who need to act on them.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemShould we use an integration platform or build it?
If the systems are mainstream and the mapping is close to standard, a platform is usually cheaper to own and faster to stand up. Building makes sense where the logic is genuinely yours — conditional routing, business-specific validation, or a system with no usable API — or where per-record platform pricing becomes punitive at your volume. It is a build-versus-buy decision like any other, and worth pricing properly.
What if one system has no API?
There is almost always a path: a database view, a file drop, a scheduled export, or a thin service in front of it. These are less pleasant than a modern API and more fragile, so they change the design and the cost. That constraint is established before scoping, not discovered during the build.
How do you handle records that fail?
They go to an exception queue a person can see, with the reason attached and the ability to correct and reprocess. Failures that vanish into a log are how integrations lose trust, and trust is most of the value.
How long does an integration take?
A clean two-system integration with good APIs and matching identifiers is short. The same integration with mismatched product codes, no test environment, and an authoritative-source question nobody has settled takes considerably longer — and the difference is knowable before you commit.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.