API development and integration
APIs and integrations that make one source of truth.
We design, build and document the interfaces between your systems, verify them against real traffic before a person reviews, and keep running them. Your CRM, billing and operations stop disagreeing.
Start a project- documented contract per interface
- 1
- sign-offs before a contract changes
- 2
- of contract changes logged
- 100%
What a governed integration gives you
-
Contracts you can read
Every API ships with its specification as a document in the record, approved before it is built.
-
Verified against reality
Automated QA replays recorded traffic through the new interface before manual review.
-
Changes are runs
A contract change is a feature request with its own approval, QA and review. Nothing breaks a consumer by surprise.
-
One source of truth
Systems read from the record instead of copying each other.
-
Legacy included
An API in front of an old system lets new work start now.
-
Operated and watched
We run the integrations after launch and the log shows every call that changed state.
When integration is the problem
Integration problems look like data problems, people problems or tool problems. They are usually contract problems.
- 01
Three systems, three truths
The customer in the CRM is not the customer in billing, and operations has a third.
- 02
Someone exports and imports
A weekly CSV is the integration layer.
- 03
The vendor connector almost works
It covers the common case and silently drops the rest.
- 04
A change upstream broke everything
Because nothing recorded what the downstream depended on.
- 05
The legacy system has no API
So nothing new can be built against it.
- 06
Nobody owns the webhook
It fires, sometimes, and nobody knows what consumes it.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
What we build
-
REST and GraphQL APIs
Designed from the contract, documented as an artifact, versioned on change.
-
System integrations
CRM, billing, payments, identity, messaging and the systems specific to your business.
-
Event and webhook pipelines
Producers, consumers and the record of what each event changed.
-
Legacy facades
An API layer in front of a system that has none.
Read more -
Data synchronization
One source of truth, with conflicts surfaced rather than overwritten.
-
Integration workflows
Multi-step exchanges with real approvals and an audit log.
Read more
How an interface is built
- 01
Map the systems
Discovery produces an inventory of what talks to what, what each depends on, and where the truth should live.
In the record Feature request, research report
- 02
Write the contract
The API specification is the design package: resources, fields, errors, versioning and who consumes it.
In the record PRD, design package
- 03
Design approval
Consumers and owners approve the contract before it is built.
In the record Logged approval
- 04
Build and document
Implementation in your accounts, with the specification kept in step with the code.
In the record Implementation package
- 05
Replay real traffic
Automated QA runs recorded requests through the interface and reports. A person reviews at the second gate.
In the record QA report, review report
- 06
Release and operate
The interface goes live under release controls, and every change to it is a new run.
In the record Release candidate, release log
Integration approaches
| Item | Vendor connector | Scripts and CSVs | Sydeso |
|---|---|---|---|
| Contract | The vendor’s | Implicit | Documented, approved, versioned |
| Coverage | The common case | What someone wrote | What discovery mapped |
| Verification | Try it | Try it | Replay of recorded traffic before review |
| On change | Hope | Find out later | A new run with gates |
| Ownership | Vendor | Whoever wrote it | Yours, in the record |
| Operation | Vendor status page | Nobody | Operated and logged |
How an engagement is structured.
-
Week one
Discovery
A week with the people who own the problem. We write the feature request, the PRD and the design package, and agree what done means.
- Ends in a PRD and a design package you own
- You approve it before anything is built
- Comes with a price for the build
-
After approval
Build
Development in short cycles against the approved scope. Automated QA writes a report on every release candidate and a person reviews it before it ships.
- Priced per project against the PRD
- Changes are new feature requests, priced the same way
- Every document is yours as it is produced
-
After launch
Operate
We deploy it, monitor it and run releases, month to month. Production is where the next feature request comes from.
- Monthly, separate from the build
- Take it in-house whenever you are ready
- The record comes with it
Questions
- Can you integrate with a system that has no API?
- Yes. We put an API facade in front of it, verified against the system’s own behavior, so new work can start while the legacy system keeps running.
- How do you avoid breaking consumers?
- A contract change is its own run. Consumers approve the new contract at the design gate, QA replays their traffic, and the release is versioned.
- Do you build the integration on our side or yours?
- In your accounts, so the integration lives where your data is.
- What about the data that already disagrees?
- Discovery decides where the truth should live. Migration moves data with history and QA reports the conflicts before a person decides at the gate.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Where does the work live?
- In your accounts. Code in your repository, infrastructure in your cloud, documents where your team can read them. We bring the process, not a dependency.
- What happens to the work if we stop?
- You keep everything: code, infrastructure, requirements, design packages, QA and review reports. There is no handover because none of it was ever ours.
Tell us what does not talk.
Name the systems and what breaks between them. We reply with the contract we would write and how we would verify it.
Start a project