Service
APIs and integrations, over data you do not control.
Provider feeds that change without warning, a legacy database nobody wants to touch, five products each fetching the same thing differently. We build the layer in between: one interface, one shape, monitored — so the systems above it stop caring where the data came from.
Scope
What this usually means in practice
- Aggregation across providers
- Many sources, each with its own format, availability and idea of a timestamp, collected and normalised into one schema. Including the ones with no API, where the data has to be extracted rather than requested.
- A single source of truth
- One versioned interface every downstream product reads, so a provider change is one fix rather than five. This is the difference between a pipeline and a permanent tax.
- Integration with what already exists
- Your ERP, CRM, accounting system or a database that predates everyone currently employed — read from and written to safely, with field-level permissions over what may cross the boundary.
- Scheduled work that survives failure
- Retries, back-off, idempotent writes and dead-letter handling, because the interesting failures are the partial ones. An alert when a source goes quiet, rather than silence that looks like no news.
- Observability from the start
- Traces per run, a record of what each source returned, and the ability to answer "why is this field wrong" by looking rather than guessing.
Leverage
Where the agents come in
Integration work is mostly reading other people's formats and writing adapters for them. That is exactly the repetitive half:
- Reading undocumented payloads and proposing the mapping, for an engineer to check against the source.
- Extraction and normalisation of messy fields — addresses, tariffs, product names — as a reviewed step inside a deterministic pipeline, never as the pipeline itself.
- Generating contract tests per provider so a silent format change fails loudly.
- Drafting the adapter for a new source, reviewed like any other contribution.
◆ marks a point where a person decides. Nothing passes it on its own.
Stack
- Laravel
- n8n
- PostgreSQL / MySQL
- Cloudflare
- JSON:API
- OpenAPI
- Redis
Built this before
Selectra
2023 — present · maintenance retainer
A telecom comparison engine fed by an automated data pipeline.
Provider plans and pricing collected from many sources, standardised and enriched with a language model, and served through one API as the single source of truth behind Selectra's telecom comparison. Built on n8n, Laravel and Cloudflare, and still maintained by us.
- n8n
- LLM
- Laravel
- Cloudflare
Selectra France
2024
Daily electricity tariff alerts for Tempo and EJP subscribers.
Direct API integration with the energy providers for daily tariff status, a backend that processes it, and a push notification service that warns subscribers before a peak-price day. With history so people can see the pattern.
- React Native
- Expo
- Laravel
- Firebase
Selectra
2023
An energy-tracking app over several providers' data.
Native Android application with Firebase authentication, a Laravel API layer fetching and validating consumption data from multiple providers, embedded web content where the web version was already the better answer, and personalised consumption alerts.
- React Native
- Laravel
- Firebase
The questions we get asked
Could we not do this with a no-code automation tool?
For a handful of steps you can, and it will be cheaper. It stops being cheaper the first time it fails silently at 3am, or when the logic no longer fits in a visual canvas. We use n8n ourselves — for orchestration, with the real logic in version-controlled code beside it.
What happens when a provider changes their format?
A contract test fails before your users notice, and the fix is in one adapter. That is the whole reason for the layer.
Do you use a language model in the data path?
Only where a rule cannot express the job — reconciling names, classifying free text, extracting from documents — and always inside a deterministic pipeline, with the output validated and the confidence recorded. Never as the thing that decides what happens next.
Tell us what the data has to come out looking like.
Bring the sources, however ugly. We will tell you what is reliably extractable, what is not, and what the layer would cost to build and to run.