customField.create now supports creating custom fields with the Currency field type.
customField.setValue and customField.setValues now accept currency values for Currency custom fields. The value must be an object with a numeric value and valid ISO 4217 currencyCode, for example { "value": 100000, "currencyCode": "USD" }.
Clarified that interviewPlan.list returns published interview plans, and only includes archived interview plans when includeArchived is true. Draft interview plans are not returned.
candidate.removeProject now validates request fields against the documented API contract and returns clearer validation errors for invalid candidate or project identifiers.
Zod-validated Public API endpoints now apply legacy request body coercion based on each field's documented schema before running validation. String-encoded booleans and integers continue to be accepted for boolean and integer fields (for example, candidateTag.list still accepts "true" for includeArchived and "25" for limit), while numeric-looking strings sent to free-text fields are preserved as strings instead of being rewritten and rejected as invalid_input.
candidateTag.list now once again accepts "true"/"false" strings for includeArchived and string representations of integers (e.g. "25") for limit. After the recent Zod validation migration these values were briefly returning invalid_input; the pre-migration contract has been restored. JSON booleans/integers continue to work unchanged.
interviewStage.info now enforces request body validation via the documented schema; invalid interviewStageId values will be rejected before reaching the handler.
applicationForm.submit now correctly accepts null for utmData and its individual fields (utm_source, utm_medium, utm_campaign, utm_term, utm_content) again. Sending {"utmData": {"utm_source": null}} or {"utmData": null} was returning invalid_input after Zod validation was added in the presigned file upload release on April 14; this has been fixed. Omitting utmData or passing valid string values continues to work as before.
applicationForm.submit now accepts application/json requests in addition to multipart/form-data. When using JSON, file field values should contain a handle obtained from file.createFileUploadHandle.
file.createFileUploadHandle now supports the ApplicationForm context for uploading files that will be attached to application form submissions.
Existing multipart/form-data submissions continue to work unchanged.
