# Integrating a system with no public technical documentation

> Some partners expose no usable technical documentation at all, without that necessarily making integration impossible: it's a type of project I handle through network traffic analysis.

- Source canonique : [https://allaux.fr/en/expertises/retro-ingenierie-api-non-documentees](https://allaux.fr/en/expertises/retro-ingenierie-api-non-documentees)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

A delivery platform, a proprietary till, a closed line-of-business tool: some systems you want to connect to a shop expose no official API and no technical documentation. Their only available interface is a web or desktop application meant for human use. The need itself is still the same as for a standard integration — syncing prices, menus, orders or stock — just without the usual starting point of API documentation.

## How I approach this kind of need

The method involves observing the network exchanges generated by the system's official interface during normal use: which requests go out, with what parameters, in what order, with what authentication. This analysis makes it possible to progressively reconstruct the behaviour of the underlying API, even when it's documented nowhere. This work demands rigour: reproducing the same headers, matching the same data format, and never treating a request that works once as reliable.

Once the behaviour is understood, I build the integration much like a standard API, with one extra point: reinforced ongoing monitoring. A system that never promised stability can change without warning, unlike a deliberately versioned API. The integration layer needs to be designed to detect a break quickly, with controlled degradation rather than a silent failure that would go unnoticed for days.

## Factors that affect the quote

- **Complexity of the authentication** — A simple access token is easy to reproduce; a more elaborate security mechanism with automatic renewal takes considerably more analysis work.
- **Observed stability of the system** — A system that changes little over time reduces the risk of a later break compared with one updated frequently.
- **Scope of the exchange needed** — Reading a single piece of data (a price, availability) is simpler than a full two-way exchange that includes creating orders.
- **How critical the synced data is** — Data displayed publicly in near real time calls for stricter monitoring than data updated once a day for informational purposes.

## Questions worth asking before starting

> Has the system shown signs of frequent changes in the past? What actually happens if the integration stops working overnight? Is there a documented alternative, even an imperfect one, that would avoid this risk?

## FAQ

### Is this approach legal?

Observing the network traffic generated by your own use of a service, within a legitimate use already authorised (a customer account, existing professional access), is a common technical practice. Each case still deserves close attention against the terms of use of the service in question.

### Is this kind of integration as reliable as a documented official API?

No, by nature: without any stability commitment from the provider, the risk of a break stays higher. That's why monitoring and fast anomaly detection are a core part of the solution, not a secondary option.

### How long does it take to reconstruct an integration like this?

It depends heavily on the complexity of the system being observed, particularly its authentication mechanism. An estimate always follows an initial observation phase, never comes before it.

### What happens if the system actually changes after going live?

Fast detection allows action before the impact spreads widely; analysing the new behaviour then follows the same method as the initial integration.