# Forward compatibility

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_size` options 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.


Warning
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.