Skip to content
07.8Capability — Integration

Not a connector. A contract.

An insurer's virtual delegate has to read a live preauthorisation record, confirm eligibility against the member database, answer from an approved knowledge base, and put the caller into the contact centre queue the moment none of that is enough. Four systems, none of them ours, each owned by a different team on its own release calendar. So the work is not the connector. It is the seam: how long we wait, what is said when nothing comes back, and who is told.

Scope a build
What it looks like

Six edges, and what each does when it fails

Integration mapOne delegate · six systemsStaticSix edges · six timeouts
Systems of record
Method
REST over TLS, read only, per-request token
Direction
Outbound — read at the moment of asking
State
answering
When it fails
Four-second timeout. The record is never guessed: the caller is told it cannot be read right now, and the request is queued for a person.
Identity directory
Method
OIDC authorisation code, no local credential
Direction
Outbound — the directory decides, we do not
State
answering
When it fails
No session is issued. Sign-in is reported unavailable, and there is no local password to fall back to by design.
Contact centre
Method
Queue API out, signed callback back
Direction
Outbound on escalation, inbound on assignment
State
answering
When it fails
Retried with backoff, then held with a stated wait and an alert raised. An escalation is never dropped quietly.
What we build

The system in the middle

Holds
The conversation, the rules, the audit trail
Reaches
Six systems, none of them ours
Assumes
Any of them can be slow, partial or gone
Right now
All six answering

Every edge here is a contract we do not control. Each is built with a timeout, a fallback, and a failure that the customer and the operator can both see.

Knowledge base
Method
Indexed pull of approved content, on publish
Direction
Inbound — only what your team has signed off
State
answering
When it fails
The last approved index is served, with the date it was approved. Answers are drawn from that index, and anything it does not cover is handed on.
Payments
Method
Hosted link out, idempotent signed webhook back
Direction
Outbound to create, inbound to confirm
State
answering
When it fails
Nothing is marked paid from our side. The payment stays unconfirmed until the callback or the reconciliation says otherwise.
Analytics
Method
Batched append-only export
Direction
Outbound, nightly
State
answering
When it fails
Events buffer and replay on the next run. Nothing a customer is waiting on is ever blocked by a reporting system.
Take an edge down

Each of these is a system somebody else owns. Stop one and read what this side does.

Press Try now to drive it yourself
أوقف نظام السجلاتأوقف مركز الاتصالأوقف قاعدة المعرفةأوقف المدفوعاتأوقف دليل الهوية
What the design does

Agreed with the owner of that system before anything was built

What went down
Nothing. The map is drawn with every edge answering.
Timeout
Every edge has one, and none of them is unbounded.
Fallback
Written down per edge, and tested against a stub that is down.
What is said, and to whom

The failure is stated to both sides — never a guessed answer, never silence

Said to the customer
The failure, in words, in the turn that it happens.
Alerted
A named owner per edge, and the duty engineer.
What is still true
Only what the working edges can prove. Nothing is inferred from a system that did not answer.
Edges

Six

Owned by us

None of them

Without a timeout

None

On a failed edge

Nothing is guessed — the failure is said

A map of one integration. The system we build sits in the middle, holding the conversation, the rules and the audit trail; six systems it reaches are drawn around it — systems of record, identity directory, contact centre, knowledge base, payments and analytics. Each edge states its protocol, whether the call goes out or comes back, and what happens when that system is slow or unavailable. The reader can then take an edge down and read the seam that runs: the timeout that fires, the fallback that is served, the words said to the customer, the person alerted, and what is still true while that system is gone. A second edge can be taken down on top of the first. No answer is invented on a failed edge, and with no session from the identity directory nothing about a record is read at all.

The interface is drawn in code in this palette, not captured. Press Try now and take an edge down: the map runs the seam that was agreed with the owner of that system — the timeout, the fallback, the words said to the customer, and the person alerted. Every system is named by its category: no client system is reproduced here, and no record on it is real.

How it runs

Six steps, and the failure is designed first

01

Name

Every system the work touches, written down with the team that owns it and the person who approves a change to it.

02

Read the contract

The real API, its authentication, its rate limits and its latency under load — not the version in the documentation.

03

Agree the seam

Timeout, retry policy, and the exact words said when the other side does not answer. Agreed with the owner, in writing.

04

Build behind an adapter

Each external system sits behind one interface we own, so a change on their side is one file on ours.

05

Test the unhappy path

Down, slow, partial and wrong, against a stub of each system. An edge we have never seen fail is not finished.

06

Watch it

Latency, error rate and fallback count per edge, with an alert for the day a fallback stops being rare.

What you get

Every edge documented, and every edge tested down

AdaptersOne per external system, with its contract written down
Failure behaviourA timeout, a fallback and a stated message on every edge
CredentialsHeld in a secret store, rotated, never in application code
Test suiteDown, slow, partial and wrong, run against a stub of each system
DashboardLatency, error rate and fallback count, per edge
DocumentationEvery endpoint, field mapping, owner and escalation path
What it connects to

Into what you already run

Systems of recordPreauthorisations, claims, orders, appointments, balances
Member databaseEligibility and entitlement, read at the moment of asking
Contact centreThe queue, the agents and the wrap-up your team already uses
Knowledge baseThe approved content your team has signed off, indexed on publish
PaymentsHosted links and signed callbacks, reconciled against the ledger
AnalyticsWhere the rest of the business already reads its numbers
Custom, not configured

Their side is theirs.

We do not choose the API, the rate limit, or the week it changes. What we choose is how our side behaves when theirs is slow, partial or gone — and that is agreed with the team that owns it before anything is built, rather than discovered in production by a customer.

Where a system has no interface, we say so and price the alternative honestly: a file exchange, a scheduled export, or a person. We do not screen-scrape a system somebody else is going to change.

Next

Send us the list of systems.

The ones the work has to touch, and the name of whoever owns each of them. We will tell you which edges carry the risk, what each should do the day it fails, and what it costs to build that way.

info@studiomedi.comContact