FlexMeasures · nhoening · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026
diff --git a/documentation/api/change_log.rst b/documentation/api/change_log.rst
@@ -12,7 +12,7 @@ v3.0-32 | July XX, 2026
 - Extended ``GET /api/v3_0/jobs/<uuid>`` with a ``result`` field containing ``unresolved`` and ``resolved`` arrays, each keyed by asset ID. For scheduling jobs, this surfaces soft state-of-charge constraint analysis: ``soc-minima`` and ``soc-maxima`` violations (with a ``violation`` magnitude) or satisfied constraints (with a ``margin`` headroom). Both arrays are empty when no SoC constraints were defined.
 - **Field canonicalization** for background job tracking:
   * The ``job`` field is now the canonical way to identify background jobs returned by `/sensors/<id>/schedules/trigger`, `/assets/<id>/schedules/trigger`, and `/sensors/<id>/forecasts/trigger` endpoints. If applicable, the triggered response now also returns a ``results-url`` pointing to the sensor-specific results endpoint, alongside the generic ``job-url``.
-  * Legacy ``schedule`` field (in scheduling endpoints) and ``forecast`` field (in forecasting endpoints) remain in responses, unchanged, for backward compatibility. New clients should prefer ``job``; see :ref:`api_background_jobs` for the full response format. These fields are not (yet) formally deprecated — see the "Planned API v4" discussion linked from :ref:`api_deprecation` for where and when their removal is being tracked.
+  * Legacy ``schedule`` field (in scheduling endpoints) and ``forecast`` field (in forecasting endpoints) remain in responses, unchanged, for backward compatibility. New clients should prefer ``job``; see :ref:`api_background_jobs` for the full response format and the "Planned API v4" discussion linked from :ref:`api_deprecation` for where and when their removal is being tracked.
 - ``GET /api/v3_0/jobs/<uuid>`` now returns ``202 Accepted`` while a job is queued or running, ``422 Unprocessable Entity`` for failed jobs, and ``200 OK`` for finished jobs. See :ref:`api_background_jobs` for the response format and polling flow.
 - ``GET /api/v3_0/jobs/<uuid>`` now also returns kebab-case metadata fields such as ``func-name`` and ``enqueued-at``, alongside the existing snake_case fields (``func_name``, ``enqueued_at``, etc.), which remain unchanged for backward compatibility. New clients should prefer the kebab-case fields.
 - Added a ``group`` field to the storage flex-model, accepted by the `/assets/(id)/schedules/trigger <../api/v3_0.html#post--api-v3_0-assets-id-schedules-trigger>`_ (POST) endpoint, referencing a power sensor representing a group of devices (e.g. a shared inverter or feeder). The group's ``power-capacity`` is enforced as a hard constraint on the group's aggregate power, while its ``consumption-capacity``/``production-capacity`` are enforced as soft constraints with default breach prices; the group's scheduled aggregate power is saved to the group sensor.

diff --git a/documentation/api/introduction.rst b/documentation/api/introduction.rst
@@ -295,9 +295,9 @@ Response field naming (``job``, ``schedule``, ``forecast``)
 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 Background-job trigger endpoints (e.g. ``POST /sensors/<id>/schedules/trigger``, ``POST /assets/<id>/schedules/trigger``, ``POST /sensors/<id>/forecasts/trigger``) and ``GET /api/v3_0/jobs/<uuid>`` return a canonical ``job`` field (and, for job status, kebab-case metadata fields such as ``func-name``) alongside older field names (``schedule``, ``forecast``, ``func_name``, etc.) kept purely for backward compatibility.
-These older field names are **not currently marked as deprecated** via the ``Deprecation``/``Sunset``/``Link`` headers described above: within API version ``v3_0`` they are additive and will keep working unchanged.
+Within API version ``v3_0``, these older field names are additive aliases and will keep working unchanged.
 
-New clients should prefer the canonical fields. Any eventual removal of the older field names is planned to happen only as part of a new, whole API version (following the same versioned deprecation/sunset flow described in :ref:`api_deprecation_hosts`), not as a field-by-field change within ``v3_0``. See the `API v4 planning discussion <https://github.com/FlexMeasures/flexmeasures/discussions/2349>`_ for the current state of that plan.
+New clients should prefer the canonical fields. Any eventual removal of the older field names is planned to happen only as part of a new, whole API version, following the same versioned deprecation/sunset flow described in :ref:`api_deprecation_hosts`. See the `API v4 planning discussion <https://github.com/FlexMeasures/flexmeasures/discussions/2349>`_ for the current state of that plan.
 
 .. _api_deprecation_hosts:
 
@@ -311,6 +311,7 @@ FlexMeasures versions go through the following stages for deprecating major feat
 - :ref:`api_deprecation_stage_3`: status 410 (Gone)
 
 Let's go over these stages in more detail.
+Hosts can customize the dates and information links used in deprecation and sunset headers with ``FLEXMEASURES_DEPRECATION_AND_SUNSET`` (see :ref:`Sunset Configuration<sunset-config>`).
 
 .. _api_deprecation_stage_1:
 

diff --git a/documentation/changelog.rst b/documentation/changelog.rst
@@ -8,7 +8,7 @@ FlexMeasures Changelog
 v1.0.0 | July XX, 2026
 ============================
 
-.. warning:: As of this release we standardize asynchronous job responses to use the ``job`` field and return HTTP ``202 Accepted`` while a background job is queued or running. See :ref:`api_background_jobs` for the response format and polling flow. Legacy response fields such as ``schedule`` and ``forecast`` will be deprecated; clients should migrate to ``job`` (see the Infrastructure / Support section below for migration details).
+.. warning:: As of this release we standardize asynchronous job responses to use the ``job`` field and return HTTP ``202 Accepted`` while a background job is queued or running. See :ref:`api_background_jobs` for the response format and polling flow. Legacy response fields such as ``schedule`` and ``forecast`` remain available for backward compatibility; clients should migrate to ``job`` (see the Infrastructure / Support section below for migration details).
 
 .. warning:: Upgrading to this version requires running ``flexmeasures db upgrade`` (you can create a backup first with ``flexmeasures db-ops dump``).
 
@@ -50,7 +50,8 @@ Infrastructure / Support
 * Upgraded dependencies [see `PR #1485 <https://www.github.com/FlexMeasures/flexmeasures/pull/1485>`_, `PR #2215 <https://www.github.com/FlexMeasures/flexmeasures/pull/2215>`_, `PR #2243 <https://www.github.com/FlexMeasures/flexmeasures/pull/2243>`_ and `PR #2348 <https://www.github.com/FlexMeasures/flexmeasures/pull/2348>`_]
 * Speed up post-processing of sensor data searches: latest-version filtering, deterministic-belief selection per event and chart-data serialization are now vectorized (up to three orders of magnitude faster on large search results) [see `PR #2328 <https://www.github.com/FlexMeasures/flexmeasures/pull/2328>`_]
 * Prepare the ``device_scheduler`` to deal with commitments per device group [see `PR #1934 <https://www.github.com/FlexMeasures/flexmeasures/pull/1934>`_]
-* Standardize job-trigger API responses to return ``202 Accepted`` and a canonical ``job`` field; legacy response fields such as ``schedule`` and ``forecast`` are preserved for backward-compatibility but marked deprecated with migration guidance in :ref:`api_background_jobs` [see `PR #2224 <https://github.com/FlexMeasures/flexmeasures/pull/2224>`_].
+* Standardize job-trigger API responses to return ``202 Accepted`` and a canonical ``job`` field; legacy response fields such as ``schedule`` and ``forecast`` are preserved for backward compatibility, and new clients should prefer ``job`` [see `PR #2224 <https://github.com/FlexMeasures/flexmeasures/pull/2224>`_].
+* Add ``FLEXMEASURES_DEPRECATION_AND_SUNSET`` so hosts can configure deprecation and sunset dates and information links per deprecated API version [see `PR #2362 <https://github.com/FlexMeasures/flexmeasures/pull/2362>`_].
 * Speed up scheduling on longer horizons using a recursive stock model, making the solve time linear with the horizon instead of quadratic (about 10x faster solves at the 2-day default horizon, 23x at 3 days) [see `PR #2282 <https://www.github.com/FlexMeasures/flexmeasures/pull/2282>`_]
 * Support storing encrypted connection secrets on organisations and assets, including utility functions, encryption key configuration, CLI commands to set and delete secrets, and UI tables that show stored secret names and optional expiration times without exposing their values [see `PR #2236 <https://www.github.com/FlexMeasures/flexmeasures/pull/2236>`_]
 * Documentation section on the modelling choice for recording measurements, forecasts and schedules under one or multiple sensors [see `PR #2217 <https://www.github.com/FlexMeasures/flexmeasures/pull/2217>`_]