---
title: "Ratify Key Date"
method: POST
path: "/thirdparties/key-dates/{key_date_id}/ratify"
tags: ["thirdparties-key-dates"]
---

# Ratify Key Date

`POST /thirdparties/key-dates/{key_date_id}/ratify`

Promote a PROPOSED key date to ACTIVE, scheduling reminder notifications.

If the proposal replaces an existing key date, that target is marked
SUPERSEDED and its unsent notifications are purged.

## Path parameters

- `key_date_id` string, uuid, required

## Request body

- RatifyKeyDateRequest — Reminder lead-days to schedule when ratifying a proposed key date. Optional fields let the user adjust the proposed row before it becomes a real key date; when omitted, the proposed row's existing values are kept.
  - `lead_days` integer[]
  - `label` string, nullable
  - `key_date_type` 'termination_notice' | 'renewal' | 'review' | 'other'
  - `month` integer, nullable
  - `day` integer, nullable
  - `first_year` integer, nullable
  - `interval_years` integer, nullable

## Response `200`

Successful Response

- KeyDateMutationResponse
  - `key_date_id` string, uuid, required
  - `status` 'proposed' | 'active' | 'superseded', required — Lifecycle of a key date. Distinct from the ``AnnualKeyDates.active`` boolean, which only toggles notifications on an already-real key date. An ``ACTIVE``-status key date may still have ``active=False`` notifications.
  - `message` string

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/kobaltlabs/apis/fastapi.md) · [All operations](https://skmtc.dev/kobaltlabs/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/kobaltlabs/fastapi/revisions/425d5b8a3c17/schema)