Software engineering / Capability
APIs & integrations.
Connect your product to the systems your team relies on, with clear contracts and handled failures.
Tell us what you’re building
When to bring us in
Sound familiar?
- Someone re-types every order from one system into another.
- An integration broke weeks ago and nobody noticed until the numbers were wrong.
- Partners want access to our data, but we have no proper API to give them.
The cost of leaving it
Someone keeps re-typing orders between systems, and errors surface as wrong numbers at month end. When a connection fails quietly, nobody knows until a customer does.
Why us
What we bring to apis & integrations.
We run what we ship
We build and operate SoulCare and SimRhythm ourselves, so releases, support and upgrades after launch are familiar work.
One codebase where it fits
SimRhythm runs on iOS, Android and the web from a single Expo app, which keeps three platforms on one release.
Code and accounts in your name
Repositories, cloud accounts and databases belong to you, and handover includes deployment steps and operating notes.
What the work includes
Stop copying the same data into three systems.
We document what each system holds and which one is the source of truth before writing any connection. APIs get versioned contracts and proper authentication. Integrations retry when a partner system is down, log what happened and make failures visible instead of quietly losing records.
API design
Versioned endpoints with documented contracts, validation and error responses.
Authentication and access
Sign-in, tokens and scopes so each client sees only what it should.
Third-party integrations
Connections to payment, mapping, accounting and other services your product depends on.
Failure handling
Retries, idempotency and logging so a failed call is recovered or reported, never lost.
Use cases
Projects we take on.
Accounting system sync
Invoices and payments raised in your product appear in the accounting package without anyone entering them twice.
A partner-facing API
A documented, authenticated API that lets partners create requests and read status without emailing your team.
Payment provider integration
Card or bank payments taken inside your product, with provider webhooks reconciled against your own records.
What you get
Outputs you can review.
- API specification and documentation
- Authentication and access model
- Integration services with retry and logging
- Data mapping between systems
- Integration tests for key flows
Technologies we use for this
Where it matters
- Health & social care Carer apps have to record visits and medication on poor signal, then sync cleanly once the phone is back online.
- Property & field services Workers capture photos and checklists on site, so uploads must survive a weak connection and still attach to the right job.
- Fintech & professional services Portals and internal tools need permissions down to the record, plus a log of who viewed, changed or approved each one.
Where AI helps
Useful, on a short leash.
Mapping messy inputs
Match free-text fields from another system, such as product names or categories, to your own codes, with uncertain matches queued for review.
AI workflow automation ↗Reading documents that arrive by email
Extract data from attachments that never come through an API, and validate it before it enters your system.
Document data extraction ↗
Where it stops: The integration itself, with its contracts, retries and error handling, should be predictable code. A model sits at the edges, not in the middle.
What’s changing
Shifts to plan for.
August 2026
Google Play targets Android 16
New apps and updates for phones and tablets must target API level 36. Extensions can be requested until 1 November 2026.
April 2026
Node.js 20 reaches end of life
The Node.js project stopped security fixes for version 20 on 30 April 2026, so services still on it need a move to 22 or 24.
April 2026
App Store requires the iOS 26 SDK
Since 28 April 2026, uploads must be built with Xcode 26. Apps can still support older iOS versions; only the build tools changed.
Process
How the work runs.
Name the source of truth
For every shared field we agree which system owns it, which settles most later arguments about conflicting data.
Write the contract
Endpoints, payloads and error codes are specified and reviewed before code, so both sides build to the same document.
Rehearse the bad days
Timeouts, duplicate messages and partner outages are simulated in testing rather than met for the first time in production.
Make failures visible
Failed calls land in a log or queue someone checks, with enough detail to replay them.
Cost
What shapes the estimate.
The other side’s API
Documented APIs with test environments are quicker to work with than undocumented or file-based ones.
Number of systems
Each additional system adds its own mapping, authentication and failure cases.
How fresh data must be
Near-real-time sync needs more care than a scheduled batch that runs overnight.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Relevant product work
See it in SoulCare.
SoulCare’s Go services run on AWS Lambda behind API Gateway, with sign-in handled through Amazon Cognito.
Explore SoulCare ↗
Common questions
Before you get in touch.
Can you integrate with a system that has a poor or no API?
Often, yes. Options include file exchange, database access or a vendor-supported connector. We assess what the system allows before choosing an approach.
Who owns the integration once it’s built?
You do. Source code, configuration and documentation are handed over, and we agree who monitors and maintains the integration after launch.
What affects integration effort?
The quality of the other system’s API, the volume and shape of the data, authentication requirements and how failures must be handled.
Further reading
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- Offline-first mobile apps for people who work without signal How to plan a mobile app that keeps working without signal, and what to settle before the first line of sync code.
- One database per tenant: isolating customer data in SaaS When each customer gets its own PostgreSQL database, and what that means for migrations, connections and running costs.