Content status: Fixture contentUpdated
Getting started
The order in which integration pieces become available, and what an integrator can and cannot do while the platform is still under construction.
Intended sequence
- 1. Read the contracts
- Versioned schemas describe every request and response shape before any implementation is available.
- 2. Run against fixtures
- Shared compatibility fixtures let an integration be exercised before a live surface exists.
- 3. Handle unknown states
- Model the case where an operation reports that its outcome is not yet established. This is required, not optional.
- 4. Pin the artefact
- Reference the release by digest so the behaviour under test matches the behaviour deployed.
The unknown-state requirement
Most integration defects in systems of this kind come from treating an ambiguous response as a success or a failure. The contracts make the third case explicit, and an integration that collapses it into the other two will fail the compatibility fixtures.
When an operation returns an unresolved state, the correct behaviour is to stop and reconcile. Re-sending the request without a stable identifier is the one action guaranteed to make the situation worse.