What We Fixed
- Entering a value a date field cannot read — say
not-a-date— now shows an error and leaves the field unchanged. Previously the raw text was saved as-is and only failed much later, when it broke search indexing for the whole contact. - Recognisable formats are still accepted and tidied up as before.
01/19/2026,3/25/2026,January 19, 2026and2026-01-19all continue to work and are stored as2026-01-19. US-styleMM/DD/YYYYordering is still read as month-first. - Clearing a date field is unaffected — an empty value is still allowed.
What Changed for Integrations
- An unreadable date sent through Zapier, Make, or the Partner API’s
people/company endpoints is now skipped rather than stored — the rest
of the request still applies (name, tags, emails, phones, and every other
custom field save as before). The Partner API’s people-update response
includes a warning naming the skipped field; other integration paths log
it server-side. - An unreadable date on a Partner API contract custom field is rejected
with a 422, naming the field, instead of being silently stored — same
as any other invalid contract field today. - No status codes, field names, or payload shapes changed for requests that
send valid dates.