Named system integrations
When a connector almost works, but the edge cases are the business.
I help with narrow two-system integration problems where a standard connector cannot handle the field mappings, source-of-truth rules, errors or exceptions that matter.
Problem diagnosis
The hard part is usually not connecting two APIs. It is agreeing what should happen when reality gets messy.
- Official connectors often work for simple cases but fail around custom fields, variants, returns, tax, inventory, order states or accounting dimensions.
- Sync errors can stay invisible until month-end reconciliation or a customer complaint.
- Different systems often use the same words to mean different things, so a “customer”, “order” or “available stock” value may not be safe to copy blindly.
The right project is a narrow connector-gap problem with a clear commercial consequence, not a vague request to integrate everything.
Responsibility
The safe version starts with the exact pair and the exact data flow.
I start by pinning down the two systems, the records that need to move, the owner for each field, the failure behaviour and the support boundary. If an official connector, product setup or certified implementation partner is the better answer, I will say so.
What I would build
The first useful version would be concrete.
- 01
Source-of-truth decisions
Each important field needs an owner, especially customer, product, order, stock, tax and fulfilment state.
- 02
Field mapping and transformation
Data is translated deliberately where the two systems do not mean the same thing.
- 03
Middleware for connector gaps
A small custom layer can handle the rules a marketplace connector cannot represent.
- 04
Retry, logs and exception handling
Failures should be visible and recoverable rather than discovered by customers or finance.
- 05
Reconciliation outputs
The business can see what moved, what failed and what needs human review.
Fit filter
Probably right, probably not.
Probably right when…
- The exact systems and data flow are known.
- A standard connector has failed or cannot model the business rules.
- Errors have a real commercial consequence and API access is realistic.
Probably not me when…
- You want generic connector setup or platform support.
- A standard app, Zapier-style automation or implementation partner is the right answer.
- The systems, ownership rules or support boundary are still vague.
First step
Start with diagnosis, not a big commitment.
The first step is a short integration triage: what needs to move, what should never move automatically, and where the current connector breaks down.
£150 per hour plus VAT where applicable. Two hours minimum for new clients. No retainer, no minimum term, no lock-in. You own everything I build.
Useful things to send before a call
- The two named systems and versions
- Current connector errors or export files
- Field mappings and source-of-truth rules
- Examples of failed orders, records or reconciliation issues
Objections
Questions this page should answer before you email.
Is this official connector support?
No. If the official connector or a certified implementation partner is the right answer, that is where the work should go.
What if the standard connector should handle this?
Then the sensible path is to fix the configuration or use the official support route. Custom middleware is only useful when the business rules genuinely sit outside the connector.
Can this integrate everything at once?
That is rarely the safest starting point. The first useful build is usually one critical data flow with clear logging, retry and reconciliation behaviour.
Next step
If this looks like your problem, send me the awkward bits.
The useful first email is short: what is breaking, what product or process cannot handle it, and what working would need to mean.