Integrations guide
Validate vendor XML contracts in CI
Turn partner samples, XSD sets, structural drift, and negative fixtures into a CI gate that catches integration breakage before deployment.
10 min read · Updated 2026-08-21
The short answer
Version the complete XSD set and redacted representative payloads, compile the schema before testing instances, and keep fixtures for valid boundaries and expected failures. Validate generated outbound XML and accepted inbound samples in CI, then compare extracted paths and cardinalities to a reviewed baseline for changes the XSD permits but your mapper cannot handle. Every failure should identify the contract, phase, file, and actionable rule.Build a closed and reviewable contract bundle
Store the entry XSD with every imported or included schema required by the contract, using a controlled catalog or repository-relative layout. Record the vendor version and acquisition source. Do not let CI fetch mutable schemas from the public network during every run.
- Redact credentials, personal data, and production identifiers from samples.
- Keep one minimal known-good instance and realistic edge cases.
- Keep negative fixtures for missing, extra, reordered, and mistyped values.
- Review schema changes and fixture expectation changes together.
Run phases that name the owner of the failure
First compile the schema set. Next validate positive fixtures and confirm negative fixtures still fail for the intended reason. Then generate your application's outbound documents and validate them. Finally parse valid inbound fixtures through the production mapping path.
1. compile schemas/vendor-v4/root.xsd
2. validate fixtures/valid/*.xml → all pass
3. validate fixtures/invalid/*.xml → all fail with expected rule family
4. generate outbound XML → validate against the same schema
5. parse inbound XML → compare mapped domain values
6. compare extracted paths/cardinality to reviewed baselineDetect compatible schema changes that break code
A vendor can make an element repeatable or add an optional choice without invalidating old documents. That may still break a mapper built around a singular field or an exhaustive enum. Compare namespace-aware paths, attributes, and occurrence assumptions as a second contract layer.
When a change is intentional, update the schema bundle, baseline, mapper, and fixtures in one reviewed change. When it is not, preserve the failing payload as a redacted regression fixture before fixing the parser.
Prove the fix
- Validate the contractCompile the XSD and exercise one positive and one negative fixture.
- Add GitHub annotationsPublish contract failures in SARIF without losing job gating.
- Compare partner samplesFind schema-compatible structural drift that still breaks mapping code.
Related guides
- Validate XML in GitHub Actions with SARIFCall the XMLDir validation API from a workflow, preserve filenames, fail the job on errors, and upload SARIF for pull-request annotations.
- Validate XML in Java with JAXPUse Java's built-in validation API safely, compile reusable Schema objects, collect SAX errors, and control external schema resolution.
- Send XML monitoring alerts to SlackConnect an account-owned XMLDir watch to a Slack incoming webhook without leaking payloads, credentials, or an unrecoverable guest workspace.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.