Software & Systems · API integrations
Interfaces between CRM, ERP, marketing tools and specialist applications that hold up in operation: with retries, a queue, monitoring and documentation. So data flows instead of being copied.
01 How you recognise it
Three starting points we see regularly. One of them is enough.
Every day, repeatedly and with errors. A job an interface can take over.
Nobody notices the missing records until a customer asks.
Older applications only offer exports and imports, which still have to run correctly.
02 What you get
Event, schedule, request, mediation or file exchange, justified by the requirements and the systems, not by habit.
No duplicates on retry, a queue for errors, monitoring, versioning, security, documentation.
Gradual activation, close monitoring in the first weeks, adjustment to the real data patterns.
03 What it looks like
Schematic example with fictitious data
An order should move from the shop into the ERP. The target system is briefly unreachable. Here is what happens.
1 · Acceptance
The shop reports the order. It receives a unique case number derived from the order number and goes into a queue. Acceptance is confirmed immediately.
2 · Transfer
The transfer into the ERP uses the case number as its key. If the same case arrives twice, no second order is created; the second transfer is recognised as already processed.
3 · Temporary error
The ERP answers with a server error. The transfer is retried at growing intervals: after 30 seconds, 2 minutes, 10 minutes, 1 hour.
4 · Permanent error
After the last retry the case moves into a visible error queue, with the time, the answer from the target system and the transferred data.
5 · Escalation
If a case sits in the error queue for longer than 30 minutes, a notification goes to the responsible person. There is no silent loss.
6 · Catch-up
Once the ERP is reachable again, the waiting cases are delivered in order of arrival. The case number prevents double bookings.
We distinguish between “try again later” and “this will never work”. A content error such as an unknown article number is not retried but reported immediately.
When it fits
Two systems should exchange data reliably, even when one of them is not answering.
What a first step delivers
An interface for one case type with retry logic, idempotency and a visible error queue.
What we need from you
API documentation and test access on both sides, plus your expectation for frequency and acceptable delay.
We only need these accesses and documents once we start working together. For a first conversation, a short description of your situation is enough.
04 Definition
An API integration connects two or more software systems through their programming interfaces so that data is exchanged automatically, by rules and traceably, without manual transfer.
The difference between an integration that works and one that holds up in operation lies in the invisible parts: error handling, retry logic, monitoring and documentation. Those are exactly the parts FIOXX builds in from the start.
05 Patterns
One system reports a change, the other reacts immediately. Ideal for status changes, new enquiries, orders.
Regular reconciliation of data sets: robust, plannable, with a defined delay.
One system asks when it needs to: availability, price, payment status. No copy, always current.
A hub connects several systems and takes over mapping, error handling and logging.
When a system has no API: structured exports and imports with checks and a log, as cleanly as possible.
06 Quality
Six properties that are not negotiable, regardless of whether we use a platform or build our own service.
The same message may arrive more than once without creating duplicate records.
Temporary errors are retried automatically; permanent ones land visibly in an error queue.
Throughput, errors and latency are monitored and reported before anyone notices a missing record.
Changes to interfaces are versioned; old and new versions can run alongside each other.
Authentication, minimal permissions, encrypted transfer, no secrets in the code.
Every integration has a description: purpose, data flows, error cases, contacts.
07 How we work
Which data, in which direction, how fast, how often? And what happens when it does not work?
What do the systems involved really offer: API, webhooks, export? Boundaries, limits and cost are clarified before building.
Event, schedule, query or mediation, matched to the requirement and the systems, not to habit.
Implementation with automated tests, test data and trial runs against the real systems in a safe environment.
Gradual activation, close monitoring in the first weeks, adjustment to the real data patterns.
Monitoring, updates when systems change, documentation kept current. An integration is something you operate, not a project you finish.
08 Next
Every process automation and every AI agent needs access to systems. Stable interfaces are therefore not a technical side note but the prerequisite for automation to run reliably in daily work. The most common combination: CRM and ERP.
09 FAQ
Platforms suit manageable logic, moderate data volumes and standard systems: quick to set up and easy to see. Your own integration becomes sensible when volume, special cases, security requirements or cost exceed the platform. We start with the simplest path that works stably.
The integration detects the outage, retries requests under control and puts undeliverable messages into a queue. After recovery they are delivered. Retry logic and idempotency aim to avoid data loss and duplicates; the specific requirements and limits we define per integration. Outages are reported, not swallowed.
Yes. We document the current state, add monitoring and error handling and stabilise what is unstable. Often that is the first step before new systems get connected.
Next step
We check the systems involved, choose the right integration pattern and build an interface that holds up in operation.