[mattshep]

The 400 example on the Pipecat Cloud REST reference shows validation issue fields that change in the next API release, when the API moves to zod 4.

• Fields: code becomes invalid_value, options becomes values, and received goes away.
• Unchanged: path, message, and the issues and name wrapper.

The new example is the real output of the API's validation for this status parameter.

Please hold the merge until that API release is in production. Until then, the current example still matches what's live.

[github-actions]

🔍 Mintlify preview for this branch: https://daily-openapi-validation-error-example.mintlify.site

[cbrianhill]

Claude Code contributed to this review.

Recommended comment; Brian approved. The updated field names match what the API returns after the validation-library upgrade, so nothing in the content needs changing; the one open item is that the requested merge hold is not enforced by anything.

No findings.

Verified:

• The three renamed/removed fields and the unchanged message wording both check out against the API: zod 4.4.3's invalid_value issue carries values and strips the offending input in finalizeIssue, while api/src/utils/zod3.ts restores zod 3's Invalid enum value. Expected ... received '...' text through z.config({ customError }).
• The issues / name wrapper and the top-level "code": "400" survive the upgrade because the new handler builds them explicitly (api/src/utils/errors.ts:186-213, with GENERIC_BAD_REQUEST = '400' at line 79). zod 4 makes issues non-enumerable on the error object, so this only holds because the handler stopped serializing the error directly.
• This is the only validation-error example in the docs repo; code search for invalid_enum_value, ZodError and Invalid parameters each returns this one file.

The description's field list matches what the new validation layer actually emits, including the removal of received, which zod 4 does not report unless input reporting is explicitly enabled.