Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Last reviewed: February 23, 2026|Editorial standard: source-backed operational guidance
Use 400 when the request is malformed or cannot be processed as a valid request message. Use 422 when syntax is understood but contained instructions are semantically invalid.
`INVALID_ARGUMENT` is used when caller input is invalid regardless of resource state. It aligns with validation-class client errors and is often represented as 400/422-style outcomes at HTTP boundaries.
Usually no. Validation failures are deterministic for the same input. Retry only after correcting request data or contract mismatches.
Use RFC 7807 Problem Details as the response envelope with stable `type`, `title`, `status`, and `instance` fields. Include field-level error paths so clients can map each failure to the exact input location. Return machine-readable per-field codes with actionable messages and keep the structure consistent across 400, 422, and `INVALID_ARGUMENT` mappings.