Versioning and deprecations
v3 is the current API. 2.1 is maintained alongside it, not phased out. This page states what is stable, what one field has already given way to, and where to look for the two things 2.1 still does that v3 does not.
v3 is current
v3 is the API this reference documents first, and the one new integrations should build against. It is not a preview or a release candidate — it is the current, supported surface.
2.1 is maintained, not retired
The 2.1 API is maintained in parallel with v3. It is not deprecated and not in end-of-life: it is the API to reach for when your integration needs something v3 does not yet expose.
The top-level email field is deprecated
Within v3 itself, one field has already been superseded: the top-level email field on container creation and update is deprecated in favor of sender.email. Both are still accepted, but new integrations should send sender.email and not the top-level field.
Historical contact aliases still recognized
Alongside the typed sender and recipient objects, a set of historical aliases inside additionalData — email, senderEmail, sender name variants, receiverEmail, receiverPhone, messageNotified — are still recognized and resolved after the typed fields and the deprecated top-level email.
What this page does not say
No dated deprecation policy is published for either API at this time.