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
- human gates 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 an artifact 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 audit 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 synchronisation
One source of truth, with conflicts surfaced rather than overwritten.
-
Integration workflows
Multi-step exchanges modelled as governed runs with gates.
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 design_approval transition
- 04
Build and document
Implementation as jobs on runners, 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, released
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 |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
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 behaviour, 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?
- Jobs run on managed runners or runners inside your network, so the integration can live 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.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
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