Validation Errors and DTO Contracts
How Zod-backed request validation appears to API clients.
Send contract-shaped JSON and treat the 422 issue list as the actionable correction surface.
Source boundary
Source boundary: AutoCore current main 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60, checked against immutable v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f.
A global Zod validation pipe runs for the API. Validation failures return VALIDATION_ERROR with issue details; client code should not depend on framework-specific exception text.
| Check | Source-backed expectation |
|---|---|
| Scope | The source contract is authoritative for field names and enums; examples in this page use placeholders. |
| Evidence | Use placeholders, timestamps, release identity, route, status, and request ID where relevant. |
| Safe action | curl -i -H 'content-type: application/json' -d '' https://api.example.invalid/api/v1/auth/register |
| Stop condition | Unknown authorization, destructive impact, secret exposure, or conflicting evidence. |
Verification
Run the safe check, record its result, and compare the outcome with the documented contract. If the result depends on external configuration or provider availability, mark it as configuration-dependent rather than claiming a product guarantee.
curl -i -H 'content-type: application/json' -d '{}' https://api.example.invalid/api/v1/auth/register
Safety boundary
Examples are non-production and use placeholders. Do not deploy, reset, force a migration, create secrets, activate providers, replay sensitive work, or expose private data from this page.