Two programs, one workflow
The customer-management application works. So does the invoicing system. Yet no new jobs have arrived since the latest update. These failures often occur at the boundary between programs rather than inside either interface.
An API is therefore more than a technical connection. Both sides need compatible expectations about data and behaviour. On 1 October 2026, Microsoft outlined its work on OpenAPI, JSON Schema and related development tools, showing the value of machine-readable descriptions and verifiable interface contracts. [1]
A contract between programs
Imagine a customer-management application handing a job to invoicing software. Which customer identifier is authoritative? Is a price inclusive of tax? May an address be absent? Does a successful response mean the request was received or that the job was fully created?
OpenAPI provides a standard, machine-readable description format for HTTP APIs. [2] That supports a shared technical foundation. It does not automatically settle the business meaning of a price or responsibility when something fails. The people involved must agree those points deliberately.
Small changes can have large consequences
A previously optional field becomes mandatory. A date uses a different format. A status message changes its meaning. Each adjustment may seem reasonable within one program while breaking its consumer.
Our recommendation is to review planned changes from the consumer's perspective too. Can older clients continue working? Is there a clearly announced transition period? Who needs to confirm the migration? A new version label alone does not protect an existing integration.
Test the handover, not just each side
A useful test goes beyond a perfectly completed sample order. Missing data, invalid values, denied permissions and interrupted responses matter as well. One particularly important question is what happens after a retry: could it create the same order twice?
Automated contract checks can expose differences early. They should be complemented by the actual workflow between appropriate versions of both applications. Separate successful test suites do not prove that the handover works.
Report errors people can act on
“Transfer failed” offers little help during a working day. A useful explanation distinguishes a missing customer identifier, expired permissions and a temporarily unavailable service. A technical operation identifier can help link the problem to a protected log.
Logs should not unnecessarily collect complete customer records, access tokens or confidential documents. Diagnosis needs focused, proportionate traceability, not indiscriminate collection of every payload.
Our conclusion
Dependable integration comes from maintained agreements, jointly tested changes and clear ownership. It is not a one-off connection task. Anyone providing or consuming an API needs to plan its evolution too. That is how two individually working programs remain one working business process.
Sources and context
Research date: 24 October 2026. Linked vendor and project information is not an independent product test. Examples and recommendations are identified as such.
[1] Microsoft: OpenAPI, JSON Schema and tooling, 1 October 2026
Read source ↗
[2] OpenAPI Initiative: specification 3.2.0, HTTP API description foundations
Read source ↗