Validation modes

Validation lets you check that traffic conforms to the contract — and, crucially, lets you see what enforcing would reject before you turn it on. There are two independent validation options:

• Request validation — checks the inbound request against the request contract.
• Response validation — checks the backend response against the response contract.

Both are conversion options and are the only two with a real per-Service override tier (system default → per service).

---

The three modes

Each validation option has three modes. The non-enforcing modes are named differently for request vs response, but they mean the same thing — log only, do not reject.

| | Request validation | Response validation | |---|---|---| | Off | off | off | | Log-only (preview) | shadow (default) | monitor (default) | | Enforce | enforce | enforce |

Off

No validation is performed. Conversion proceeds on a best-effort basis.

Shadow (request) / Monitor (response) — the preview mode

This is the default, and the reason validation de-risks rollout. In shadow/monitor mode the platform evaluates the contract on every call and records every would-be failure — but does not change behavior. Traffic is neither rejected nor altered.

That gives you a data-driven preview: turn shadow/monitor on, let real traffic flow, and inspect the would-be-rejected calls in observability. You can then see exactly what enforcing the contract would reject — before you flip the switch — and fix the data, the contract, or the field override accordingly instead of guessing.

Enforce

Once the shadow/monitor data is clean, switch to enforce. Now non-conforming traffic is rejected with a clear, coded error instead of being logged and passed through:

• Request enforce rejects a non-conforming inbound request before the backend is called — so a bad request never reaches your backend.
• Response enforce rejects a non-conforming backend response, surfacing it as a coded error rather than passing a contract-violating payload to the consumer.

---

Recommended rollout

off / (default shadow|monitor)  →  inspect would-be failures  →  fix  →  enforce

1. Start in shadow / monitor (the default). Let representative traffic run.
2. Review would-be failures in observability — identify whether they're genuine contract violations, stale examples, or fields that need an override.
3. Resolve them (correct the data upstream, adjust a field override, or relax the contract).
4. Switch the service to enforce once the would-be-failure stream is clean.

Set the option platform-wide under Settings → Conversion defaults, then override per service under Services → your service as different services reach enforcement-readiness at different times.

---

Per-field validation regexes

Riding on top of the validation mode are per-field validation regexes — a pattern constraint attached to a leaf field (UTF-8 / Hebrew-aware). These are direction-aware (separate request and response patterns) and are authored as a field-level override.

• Under shadow / monitor a regex mismatch is logged as a would-be failure.
• Under enforce a regex mismatch is rejected.
• Either way, the regex is emitted into the generated OpenAPI v3 schema as a pattern, so the published contract documents the constraint.

This is also where the onboarding-time "string fields without a validation regex" setting fits: it governs whether the platform notifies, suggests, or silently applies a generic regex to string fields that arrive with no XSD pattern during mapping generation (see the conversion options reference).

---

Next reads

• Conversion options reference
• Field-level overrides
• Observability — where would-be failures are surfaced.

---

All Specaria SOAP to REST docs