Payments · ERP / CRM · Data

API & system integration
that keeps data moving.

Connect your product to the services your business relies on. We build API integrations and backend services that keep data moving between applications with explicit ownership, permissions and failure handling.

Discuss your integration ↗

From scope to delivery

What we can build
together.

We map the systems of record, API limits and synchronization rules before building. Integration scope includes authentication, retries, logging and reconciliation where appropriate. Documentation explains the data flow and how to diagnose failed events after handover.

Business system integrations

Connect CRM, ERP, commerce and internal tools through available APIs, webhooks and scheduled synchronization.

Payments & subscriptions

Integrate payment providers, subscription states and billing events with careful handling of retries and duplicate notifications.

Backend modernization

API design, data migration and service refactoring with a staged rollout that accounts for existing consumers.

Who this is for

Teams losing hours to copy and paste between systems.

Integration projects usually begin with a symptom and not with a technical request. Typical starting points:

Staff re-keying data. Orders typed from the shop into the accounting package, leads copied from a form into the CRM, stock levels updated by hand in two places.
A product that needs to take money. One-off payments, subscriptions, refunds, invoices and the webhooks that keep your database in step with the payment provider.
Customers asking for an API. B2B buyers want to connect your product to their own systems, and a spreadsheet export is no longer enough.
An ageing backend. One service does everything, nobody wants to touch it, and new features need a cleaner boundary to build against.
Numbers that disagree. The dashboard, the finance system and the warehouse each report a different figure because nothing reconciles them.

Where the underlying problem is a manual process and not a missing connection, a small purpose-built tool may be the better answer. We cover that under internal tools and dashboards and custom software development.

The process

Understand the data first.
Then write code.

Most integration failures are decided before development starts, by assumptions nobody checked against the real API or the real data.

How we work in detail ↗

Discovery and API review

We read the documentation, obtain sandbox access and test the endpoints that matter. We look at rate limits, pagination, authentication, webhook reliability and the gaps between the documentation and actual behaviour. Output: a short feasibility note.

Data mapping and rules

A field-by-field mapping between systems, including which system is the source of truth for each record type, how conflicts are resolved and what happens to records that fail validation. You sign this off before the build.

Build and test against sandboxes

Development in increments, with automated tests for the failure cases: timeouts, duplicate webhooks, partial outages and malformed responses. A staging environment runs against test accounts.

Staged rollout and handover

Where possible the integration first runs in read-only or shadow mode, with results compared against the manual process. It is then switched on for a subset of records, and then for everything. Handover includes the repository, configuration and a runbook.

Technology approach

Assume every call can fail, because eventually it will.

Moving data between two systems on a good day is easy. The engineering lies in what happens when a network call times out halfway, a webhook arrives twice, or the other system is down for an hour. We build mainly with Node.js, TypeScript and PostgreSQL, and the patterns matter more than the language.

Problem	Pattern we use	What it prevents
The same event delivered twice	Idempotency keys and deduplication on event IDs	Double charges, duplicate orders
Temporary outage on the other side	Job queue with retries, backoff and a dead-letter list	Silent data loss
Webhooks that never arrive	Periodic reconciliation against the source API	Systems drifting apart unnoticed
Rate limits	Throttled workers and batching	Blocked API keys during bulk syncs
Forged or replayed webhook calls	Signature verification and timestamp checks	Unauthorised state changes
Secrets and tokens	Environment-level secret storage, scoped keys, token refresh handling	Credentials in the repository, expired connections
Nobody knows it broke	Structured logs, failure alerts, an admin view of failed events with a retry button	Finding out from a customer

For your own API we default to REST with an OpenAPI description, because every client and tool understands it. We use GraphQL or other styles when the consumers clearly benefit. Breaking changes are versioned, and existing consumers receive a migration path instead of a surprise.

Pricing factors and common mistakes

What makes an integration cheap or expensive.

We price integration work against a written scope once the API review is done. The main drivers are:

API quality. A modern, documented API with a sandbox takes days. An undocumented one with no test environment takes weeks, and the estimate carries a risk margin.
Direction. One-way sync is far simpler than two-way sync, where conflict rules are needed.
Number of record types. Customers, orders, products, invoices and payments each have their own mapping and edge cases.
Timing. Nightly batch is cheaper than near-real-time.
Historical data. Migrating and cleaning years of existing records is often larger than the ongoing sync.
Money. Anything that touches payments receives more testing and reconciliation. That is where the budget should go.

Mistakes we try to keep clients out of

Building only the happy path. The demo works. The first outage produces a week of manual clean-up.
No single source of truth. If two systems can both edit a customer’s address and nobody has decided which wins, the data will degrade.
Treating webhooks as guaranteed. Providers retry, reorder and occasionally drop events. Reconciliation is part of the design and not an optional extra.
Skipping the sandbox. Testing against production accounts to save time usually ends up costing more of it.
Chaining automation tools beyond their limits. No-code connectors work well for simple flows. Once there are branches, retries and volume, a small dedicated service is cheaper to run and easier to debug.

Fit

When to bring BBR in,
and when not to.

Integration work ranges from a two-day webhook to a multi-year enterprise programme. We sit towards the smaller, more focused end.

Good fit

We are likely a strong match if

You have two to six systems to connect and a clear idea of what should flow between them
You are adding payments or subscriptions to a product and want the billing states handled correctly
Your product needs a documented public API and webhooks for customers
You want the integration code and runbook in your own repository, with no dependency on a proprietary platform

Not a fit

We will probably point you elsewhere if

You need a certified implementation partner for a specific ERP or CRM vendor
The work is a large enterprise service bus or data warehouse programme with a dedicated on-site team
A simple no-code automation already covers the need reliably
The integration depends on bypassing a vendor’s terms of service or access controls

Questions

Frequently asked
questions.

Can you integrate without replacing our current system?

Often, yes. We review the available APIs and constraints first, then propose an integration boundary that preserves existing workflows where practical.

What if the system we need to connect has no API?

There are usually fallbacks: scheduled file exports and imports, a database read replica, email parsing, or the vendor’s own integration platform. Each is more fragile than a documented API, so we say which one we would use, what can break and how failures would be noticed. If the only route is scraping a web interface against the vendor’s terms, we will advise against it.

How long does a typical integration take?

A single well-documented API such as a payment provider or email service is commonly one to two person-weeks including error handling and tests. Two-way synchronisation between business systems with different data models takes longer, and the range depends mostly on how many record types are involved and how conflicts are resolved. We estimate after reviewing the API documentation and a sample of real data.

Who maintains the integration after it goes live?

You receive the code, configuration and a runbook that explains the data flow and how to diagnose failed events. Third-party APIs change, so some upkeep is unavoidable. You can handle it in-house, or arrange ongoing support with us, scoped separately from the build.

Do you build public APIs for our own product?

Yes. That covers resource design, authentication with API keys or OAuth, rate limiting, versioning, webhooks for your customers and reference documentation. It is often part of a larger SaaS build and can also be a standalone project on an existing backend.

Your next move

Systems that should talk to each other?
Tell us which ones.

List the systems involved, what data needs to move between them and how often. We reply with questions about the available APIs and a suggested integration approach.