Two systems that refuse to talk. We make them talk, and keep them talking.
API middleware, scheduled synchronisation, webhook pipelines, and the monitoring that tells you a job failed before a colleague does.
Systems
Where your data already lives
- Bullhorn
- Candidate, contact and job records kept in step with career sites and reporting, through its REST API.
- Salesforce
- Accounts, opportunities and custom objects synchronised with billing and delivery.
- ServiceNow
- Tickets, requests and CMDB records created where the work starts, not retyped by hand.
- UKG
- Worker, org and time data moved between HR and the systems that depend on it.
- Custom and legacy systems
- In-house applications, ERPs with a decade of local changes, SFTP drops, SQL views, SOAP endpoints, the load-bearing spreadsheet.
Recruiting
CRM
Service management
HR & workforce
Everything else
We are an independent engineering team, not a reseller or certified partner of these vendors: we build against their documented APIs, with credentials you issue and revoke.
What we usually find
The integration you have today is a person
- Manual copy and paste between systems
- Export, reformat, paste. It works until they are on holiday, and it caps how fast the process can run.
- Duplicated data that has started to diverge
- Three systems, three versions of the truth, no rule for which wins. Reporting becomes a debate, not a number.
- No owner for the flow itself
- Every system has an owner; the space between them has none. Scripts from someone who left run on a box nobody wants to reboot.
- Processes you cannot observe
- When a sync stops, nothing tells you. You find out days later, with no log to reconstruct what was lost.
01
02
03
04
Name the two systems and the record that has to move.
You get back the interfaces, the failure points, and what we would build first.
What we build
A layer you can watch, log and turn off
- API middleware
- One tested service owns authentication, field mapping, validation and business rules.
- Scheduled synchronisation
- Incremental jobs move only what changed, with watermarks so a restart resumes. Slower full reconciliation catches drift.
- Webhooks and event pipelines
- Signature verification, a queue behind the endpoint so a slow consumer never drops a delivery, replay from stored payloads.
- Control dashboard
- Last successful run, records in and out, current failures, and a retry button that needs no ticket with us.
Failure behaviour
What the system does when something goes wrong
Integrations fail at 02:00 on a Sunday: a 503, a payload that changed shape, a duplicated delivery. This is the part we design first.
Retry with backoff
Timeouts, 429s and 5xx are retried on an exponential schedule with jitter and a bounded attempt count, so a struggling target system is not hammered by our own traffic.
Idempotency
Writes are keyed on a stable business identifier, or an idempotency key where the target supports one: replaying a message twice produces one record. That is what makes retry and replay safe at all.
Dead letter queue
Messages still failing after their retries are parked with the original payload, the error and the correlation id. Nothing is dropped silently; a fixed batch can be replayed.
Alerting that reaches a person
Failed runs, dead letters above a threshold and jobs that did not run at all alert into the channel your team already watches. A missing heartbeat counts as a failure.
Rollback and cutover safety
Deployments are versioned and reversible. A feature switch pauses a flow without a release and points it back at the previous behaviour while the fix is prepared.
Auditability
Each record carries a correlation id through the logs, so “where did this value come from, and when” is a query, not an investigation.
A case you can open
An integration switched off without breaking anything.
Most of our work is covered by confidentiality agreements. This one is not, and it is online.
For Automobili Zupi the public catalogue synchronised hourly with Multigestionale Motori, the back office Italian dealerships use to publish their listings on Subito.it. Only changed vehicles were updated, cars dropped from the stock list were archived rather than deleted, and images were pulled locally without ever overwriting the ones uploaded by hand at the showroom.
When the provider restricted API access, the sync was stopped with a single command: the catalogue stayed up, the hand-entered data was untouched, no record was lost. It is why we design failure behaviour first — being switched off is one of those cases, and it always comes.
Architecture & security
How it is built and who can see what
Credentials
Service accounts you issue, scoped to what the integration needs, kept in a secret manager, rotatable without a code change. No shared personal logins.
Data in transit and at rest
TLS everywhere, encrypted storage, logs scrubbed of the fields you flag as sensitive. Retention and hosting region agreed before we process real data.
Environments
Development and staging run on vendor sandboxes, never on production data by default. Promotion is the same automated path every time.
Monitoring
Health checks, run history, throughput and error rates, in your dashboard and in the observability tooling you already run.
How we work
From flow map to running integration
Map the flow
Which records move, in which direction, triggered by what, and who owns each field.
Check the interfaces
Permissions, rate limits, and where the API stops short of what the process needs. Tested on a sandbox, not on a slide.
Build the narrowest useful slice
One direction, one record type, end to end, with logging and retry from the first commit.
Run it in parallel, then cut over
The new flow runs alongside the old one, reconciled, and takes over only once the numbers match.
Hand over the controls
Dashboard, alerts, runbook and code in your hands. Keep us on as the systems evolve, or do not.
Not sure the integration is worth building yet?
Send the flow. If the answer is a configuration change in a tool you already own, we will say so.
Questions we get
Before you send anything
Which systems can you integrate?
Anything with an API, a webhook, a database we may read, or a scheduled file exchange: Bullhorn, Salesforce, ServiceNow, UKG, plus internal and custom systems. Where a product has no usable interface for what you need, we say so during discovery instead of building something fragile around it.
Are you an official partner or reseller of those platforms?
No. We are an independent engineering team, building against the documented public APIs of the edition you already license, with credentials your administrators issue and can revoke. Any partner-only feature or add-on stays a decision between you and the vendor.
Who owns the integration once it is live?
You do: the code, the repository, the infrastructure definitions and the runbook. We can keep operating it, hand it over with a walkthrough, or both in sequence. Nothing is locked behind an account only we can access.
What happens when the vendor changes their API?
Contracts are validated at the boundary, so a changed or missing field fails loudly in a known place instead of writing bad data downstream. Version pinning, a sandbox staging environment and alerting on schema and error-rate changes are part of the build, not an upsell.
Can you work with a system nobody documented?
That is most of the work. We map what actually moves today, spreadsheets and manual steps included, and validate our reading of it with the people doing the job before writing code.
Get in touch
Map your integration flow.
Tell us the two systems, the record that has to move, and what breaks today.
- Locations
- Italy · Czechia · Japan