FlexMeasures · Flix6x · Sep 7, 2026 · Jul 27, 2026 · Jul 27, 2026 · Jul 27, 2026
diff --git a/documentation/api/change_log.rst b/documentation/api/change_log.rst
@@ -25,7 +25,7 @@ v3.0-32 | August 11, 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.
 - Sensor-data ingestion normally uses a connected ingestion worker, and scheduling and forecasting triggers normally return ``202 Accepted``. As a compatibility exception, configured legacy clients receive synchronous ingestion, ``200 OK`` from these triggers, and the legacy ``400`` response while polling an unfinished schedule. Configure this with ``FLEXMEASURES_LEGACY_JOB_RESPONSES_MAX_INCOMPATIBLE_CLIENT_VERSION``.

diff --git a/documentation/api/introduction.rst b/documentation/api/introduction.rst
@@ -297,9 +297,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:
 
@@ -313,6 +313,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
@@ -33,8 +33,8 @@ Infrastructure / Support
 * Shrink the Docker image by excluding dev-only dependencies, pruning stray ``docs``/``examples`` payloads bundled by ``sktime``/``scikit-base`` (issue: https://github.com/sktime/sktime/issues/10891), stripping the symbol tables that the compiled extensions ship with, and dropping the ``sktime``-backed belief-formation extra of ``timely-beliefs``, which FlexMeasures does not use [see `PR #2438 <https://www.github.com/FlexMeasures/flexmeasures/pull/2438>`_, `PR #2439 <https://www.github.com/FlexMeasures/flexmeasures/pull/2439>`_ and `PR #2440 <https://www.github.com/FlexMeasures/flexmeasures/pull/2440>`_]
 * Require an exact ``uv`` version (``0.12.7``) via ``[tool.uv].required-version``, which keeps ``uv.lock`` changes reproducible across local development, CI, Docker and Read the Docs, but does mean that anyone running ``uv`` in a FlexMeasures checkout — plugin developers and self-hosters included — needs that same version [see `PR #2451 <https://www.github.com/FlexMeasures/flexmeasures/pull/2451>`_]
 * Train and predict a forecaster's per-horizon models side by side rather than one after another, which cuts the training time of a long forecast horizon several-fold while leaving the forecasts themselves unchanged [see `PR #2479 <https://www.github.com/FlexMeasures/flexmeasures/pull/2479>`_]
-
 * The UI's JavaScript modules can now be tested, by running them in a headless browser from pytest, without adding a Node.js toolchain [see `PR #2435 <https://www.github.com/FlexMeasures/flexmeasures/pull/2435>`_]
+* 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>`_].
 
 Bugfixes
 -----------