Integration mapping
We inventory every system, entity and flow and record who owns each. The map shows where data originates, where it is copied, and which direction each sync runs.
Services / Automation & Integration
API, webhook and CRM/ERP integration, built to be owned.
We connect CRMs, ERPs, finance tools, SaaS platforms and in-house systems so each piece of data has one owner, moves once, and leaves a trail when something goes wrong.
Why integrations break after they ship.
Most integration problems are not caused by a difficult API. They come from unanswered questions: which system owns the customer record, what should happen when two tools disagree, who notices when a sync stops in the middle of the night, and whether a retry can create a duplicate invoice. When those questions stay implicit, a connector that worked in the demo slowly turns into a source of quiet data drift.
As integration consultants, we start with those questions rather than with code. We map the systems involved, agree a source of truth for each important entity, and decide the direction and timing of every sync. Only then do we build connectors, webhook handlers or event pipelines, with failure behaviour designed up front instead of discovered in production.
The result should be something your team can read, operate and change without us: tested code in your repository, documented mappings, and alerts that reach a named person.
Typical situations
Problems this work is meant to solve.
If several of these sound familiar, the issue is usually the design between systems, not any single tool.
- Systems disagree about the same customerSales, billing and support each hold a slightly different version of the truth, and staff spend time deciding which one to believe.
- Manual re-keying between toolsOrders, invoices or tickets are copied by hand from one system into another, with typos and delays that nobody measures.
- Webhooks that stop silentlyA vendor changes a payload or an endpoint times out, and the integration fails without anyone being told until a customer complains.
- Duplicates after retriesA timeout triggers a retry, the first request had actually succeeded, and now there are two orders, two payments or two contacts.
- A connector nobody understandsThe person who built it has moved on, there is no documentation, and nobody is comfortable changing it.
- A CRM or ERP change aheadA platform migration is planned and every integration touching it needs to be inventoried, re-pointed and tested.
How we build integrations
Engineering choices that keep data trustworthy.
These are defaults, adjusted to each system’s API and your volume, not a fixed framework.
Clear data ownership
Each important record (customer, order, invoice, product) gets one source of truth. Other systems receive updates from it rather than competing to edit the same field.
Idempotent writes
Processing the same message twice must have the same effect as processing it once. We use idempotency keys, natural identifiers or upserts where the target API supports them.
Retries with limits
Transient failures are retried with backoff and a ceiling. Permanent failures are not retried forever; they are parked in a failure queue for a person to review.
Careful webhook handling
Incoming webhooks are verified where the provider signs them, acknowledged quickly and processed asynchronously, so a slow downstream system does not make the sender give up.
Reconciliation and alerting
Scheduled checks compare counts or totals between systems and flag drift. Alerts go to a named owner with enough context to act, not to a shared inbox nobody reads.
CRM and ERP integration.
CRMs and ERPs are usually the hardest systems to connect, because they hold the records that matter most and enforce their own validation, rate limits and approval rules. A CRM–ERP integration has to answer when a won deal becomes an order, which system assigns customer numbers, how tax and currency fields map, and what happens when the ERP rejects a record the CRM considers valid.
We record these as explicit decisions in the mapping document, not as comments buried in code. Where a native connector or an integration platform is a reasonable fit, we say so; custom code is not always the right answer. Where custom work is justified, we keep it small, tested and in your repository.
Webhook integration.
Webhooks deserve particular care. Providers differ in how they sign, retry and order events, and most do not promise exactly-once delivery. We design handlers to tolerate duplicates and out-of-order events, and document each provider’s behaviour so the next engineer does not have to rediscover it.
For flows that span several steps, such as an order that touches payment, stock and shipping, we make the intermediate state visible, so a failure halfway through can be resumed or reversed instead of fixed by hand in three places.
See business process automation and the other integration services
Scope and limits
What an engagement covers, and what it does not.
Scope, timeline and price are agreed per engagement after a first conversation.
- Typical scope. Discovery and mapping, integration design, connector or webhook implementation, tests, monitoring and handover. Larger programmes are split into separately agreed phases.
- Your accounts, your code. Repositories, API credentials and integration-platform accounts stay under your ownership. Never include passwords or API keys in an inquiry brief.
- Vendor limits. We cannot change what a vendor API allows. Where rate limits, missing endpoints or licence tiers constrain a design, we document the trade-off instead of building a fragile workaround.
- Not included by default. Ongoing operation after handover. It is available separately as managed operations, under written scope and response terms.
- No guaranteed outcomes. We do not promise specific savings or error-rate reductions. We agree acceptance criteria you can verify instead.
FAQ
Questions buyers usually ask.
Do you work with a specific CRM or ERP?
We are not tied to one platform. We work against documented APIs and webhooks, and we will tell you early if a system’s API cannot support what you need. Mentioning a tool on this site does not imply a partnership or endorsement.
Should we use an integration platform or custom code?
It depends on volume, complexity, how often mappings change and who will maintain them. Low-code platforms suit simple, low-volume flows that business users own. Custom services suit complex logic, high volume or strict testing needs. We compare both against your real flows before you commit.
What does idempotency mean in practice?
A message can be processed more than once without side effects. If a request times out and is retried, the target system ends up with one order, not two. It is the main defence against duplicates in any integration that retries.
How will we know when an integration fails?
Failures are logged with context, retried where it is safe, and routed to a named owner through an alerting channel you choose. Records that cannot be processed are held for review rather than dropped.
Can you take over an integration someone else built?
Usually, yes. We start with a review of what it does, where it is fragile and what is undocumented. You get a written assessment before any rewrite is proposed.
What should we prepare before a first conversation?
A list of the systems involved, which one you believe owns each important record, and the failures or manual steps that hurt most today. System names only: never send credentials.
Related
Where to go next.
- Automation & integration services. Business process automation and API & system integration, side by side.
- AI agents with human approval. Once data flows reliably, bounded agents can act on it, with a person approving consequential steps.
- Linux & DevOps engineering. Hosting, pipelines, backups and monitoring for the services that run your integrations.
- Our approach. Map, design, build, gate, operate: the five stages behind every engagement.
- Prepare an inquiry brief. Organise your systems, constraints and goals before a first conversation. Preview only: the brief is built in your browser and nothing is sent.
Map your integrations before you build more.
List your systems and the flows that hurt. The contact channel is not live yet, so the brief stays in your browser.