New optional API field. Can the application still read the response?

The schema is a starting point, not a verdict

Adding an optional field is additive in the API description, but a known supported client rejects the resulting response. For the current consumer set, broad rollout is therefore not operationally compatible. Because the contract never required unknown fields to be ignored, the producer cannot quietly transfer the migration cost to that client.

Bound the change and gather evidence

Do not expose the field universally while the supported client remains strict. Keep the field hidden, expose it only through an explicitly negotiated response profile or version, or introduce a new contract version when the behaviours cannot coexist. In parallel, fix the client and record an evolution rule for future versions.

Run a contract test using that exact app version: the response includes deliveryWindow, while the client must still read the established fields correctly. Then use a limited rollout and observe deserialization failures and client versions. A green OpenAPI diff tests the model, not the user.

Boundary of the decision

If the producer controlled every consumer and could enforce a coordinated update, that deployment could be sufficient. This scenario does not allow it. Versioning is not punishment for change; it is a tool when an earlier promise cannot be preserved.