The Connect API evolves over time. To keep your integration resilient, build your client to be forward-compatible so that additive, non-breaking changes are ingested smoothly and never break your flow.
As a general rule — independent of any individual endpoint or its lifecycle stage — treat Connect API responses as forward-compatible:
- New fields may be added. New fields may appear at the top level or within nested objects.
- New values may be added to existing fields. Fields that draw from a fixed set of values (for example the
image_sizeoptions on the property inventory stream) may gain new values over time.
To handle this safely, build your client to:
- Ignore properties it does not recognise, rather than failing when an unexpected field appears.
- Tolerate unknown values for enumerated fields, rather than rejecting the whole record.
Do not implement strict schema validation that rejects unknown fields or unknown enum values. Additive changes are considered non-breaking and may be rolled out without prior notice; strict validation would cause such changes to break your integration.
Breaking changes — such as removing or renaming a field, or changing its type — are handled separately and communicated in advance.