Traceability APIs: what to ask a software vendor before you sign

An API (application programming interface) is what lets two pieces of software exchange data automatically — between a traceability tool and a till, an ERP, or a trading partner's system. This guide translates, in non-technical language, the questions that matter before committing to a tool whose API will be put to work.

What “having an API” does not guarantee

Almost every vendor advertises “an API available” — the existence of an API says nothing about its real quality. What separates a usable API from one that is advertised but unusable in practice comes down to specific details, listed below.

The questions to ask

1. Is the documentation public and up to date? Documentation accessible without first creating an account, and in step with the version in production, lets a contractor cost an integration project without depending on the vendor's sales support.
2. What call rate is allowed? A limit that is too low (number of requests per minute) can block an integration as soon as a significant volume of data has to flow, notably during an initial import of historical data.
3. Which export formats are available? A standard format (CSV, structured JSON) makes integration easier; an undocumented proprietary format makes you depend on the vendor for every change.
4. What availability is contractually guaranteed? An availability commitment (often expressed as an annual percentage) gives a basis for assessing the risk of interruption, in the absence of any guarantee of flawless operation.
5. Is a full data export possible without the API? A fallback (a complete manual export) protects you if the API itself suffers a prolonged outage.

Reversibility: the most frequently overlooked question

Reversibility means: if the business changes tool in two or three years, can it recover all of its data, in a format reusable elsewhere? This question is asked before signing, not at the moment of changing tool — a contract or terms and conditions that stay silent on this point expose you to de facto dependence, even without an explicit exclusivity clause.

What a developer or contractor checks technically

Without going into technical detail, a contractor in charge of the integration will generally check:

• The authentication mechanism (how access is secured).
• Error handling (what happens when a call fails, and how to detect it).
• The presence of webhooks (automatic change notifications), to avoid querying the API constantly.

You do not need to understand these mechanisms in detail to steer the project — it is enough to know they exist and to ask your contractor to check them before signing.

Common mistakes

• Signing without having the API checked by a technician, even an external one, before committing to an integration project.
• Ignoring the question of reversibility until the day it becomes necessary — too late to negotiate better terms.
• Relying on a sales demonstration of the API rather than a real test on a use case representative of the expected volume.

Checklist

1. Ask for access to the public documentation before any commercial commitment.
2. Check the call rate and the available export formats.
3. Ask for the contractual availability commitment, if there is one.
4. Clarify reversibility and full data export explicitly.
5. Have the API checked by a technician before signing, even for a modest project.