Integration Validation

[digitalrisedorset]

Summary

Introduce integration validation capabilities to the Health Engine to continuously verify that external systems remain operational and compatible.

Rather than validating individual APIs, the Health Engine validates that business integrations continue to deliver their expected outcomes.

Objectives

• Validate third-party integrations.
• Execute integration-specific health checks.
• Verify API contracts remain valid.
• Detect integration failures before they impact customers.
• Report integration health through the Health Engine.

Examples

• ERP inventory synchronisation
• Payment gateway connectivity
• Search service availability
• Recommendation engine
• Shipping providers
• CRM synchronisation

Future Enhancements

• Contract validation
• Synthetic integration tests
• Latency thresholds
• Automatic remediation
• Integration-specific health scores

[digitalrisedorset]

Implementation Notes

The Health Engine is not intended to implement integrations itself.

Instead, it should orchestrate existing integration validation capabilities through a pluggable architecture.

The table below captures candidate integrations that should be investigated as the project evolves.

Validation	Candidate Systems	Notes
API availability	HTTP Health Endpoints	Verify dependent services are operational.
API contract validation	OpenAPI, Pact	Ensure interfaces remain compatible.
End-to-end integration	Playwright	Validate complete business workflows across multiple systems.
ERP integration	ERP APIs	Verify business data can be exchanged successfully.
Payment integration	Payment provider APIs	Validate payment services remain operational.
Search integration	OpenSearch, Elasticsearch, Algolia	Verify search services respond correctly.
Authentication	OAuth2, OpenID Connect	Validate authentication and authorisation flows.
Messaging	RabbitMQ, Kafka	Verify asynchronous communication remains healthy.
Observability	OpenTelemetry	Correlate integration failures with distributed traces.

This table is intentionally non-prescriptive and should evolve as additional integration providers, protocols and standards are identified.