---
title: "Get Key Dates For Run"
method: GET
path: "/thirdparties/key-dates/run/{run_id}"
tags: ["thirdparties-key-dates"]
---

# Get Key Dates For Run

`GET /thirdparties/key-dates/run/{run_id}`

## Path parameters

- `run_id` string, uuid, required

## Response `200`

Successful Response

- ContractRunKeyDates
  - `key_dates` KeyDateRow[], required
    - `key_date_id` string, uuid, required
    - `vendor_company_name` string, required
    - `vendor_website` string, nullable
    - `vendor_id` string, uuid, required
    - `file_id` string, uuid, nullable
    - `run_id` string, uuid, nullable
    - `source_type` 'run' | 'contract' | 'review' — What kind of entity a key date was derived from. Generalizes the historical ``run_id`` linkage so a key date can point at a contract-analysis run or a formal contract entity.
    - `source_id` string, uuid, nullable
    - `status` 'proposed' | 'active' | 'superseded' — 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.
    - `replaces_key_date_id` string, uuid, nullable
    - `key_date_type` 'termination_notice' | 'renewal' | 'review' | 'other', required
    - `label` string, nullable
    - `month` integer, required
    - `day` integer, required
    - `first_year` integer, required
    - `interval_years` integer, required
    - `active` boolean, required
    - `contract_filename` string, nullable
    - `contract` KeyDateContractSummary
      - `contract_id` string, uuid, required
      - `title` string, required
    - `services` KeyDateServiceSummary[]
      - `service_id` string, uuid, required
      - `name` string, required
    - `assignments` VendorAssignmentResponse[]
      - `assignment_id` string, uuid, required
      - `vendor_company_id` string, uuid, required
      - `user_id` string, uuid, required
      - `user_first_name` string, required
      - `user_last_name` string, required
      - `email_address` string, required
    - `notifications` KeyDateNotification[]
      - `notification_id` string, uuid, required
      - `lead_days` integer, required
      - `scheduled_for` string, date, required
    - `next_occurrence_date` string, date, nullable
    - `reminder_schedule` KeyDateReminderSchedule — The reminder cadence for a key date's *next* occurrence, sent reminders included. ``KeyDateRow.notifications`` deliberately carries only unsent rows, so once the first reminder of a cadence has gone out it can no longer describe the configured cadence ("90, 60 & 30 days before") or say how far through it we are. This can, without changing ``notifications`` — the reminder editor prefills from that list and ``POST /{id}/notifications`` only creates rows that don't exist yet, so widening it to include sent offsets would make the editor propose duplicates of reminders that already went out. Populated by ``attach_reminder_schedules`` in ``backend.helpers.key_dates``; unset by default because building it requires an extra query.
      - `occurrence_year` integer, required
      - `lead_days` integer[], required
      - `sent_lead_days` integer[], required
      - `next_scheduled_for` string, date, nullable
  - `parsed_dates` ProspectiveKeyDateRow[], required
    - `key_date_type` 'termination_notice' | 'renewal' | 'review' | 'other', required
    - `upload_id` string, uuid, nullable, required
    - `date` string, date, required
    - `label` string, required

## 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/3ff4c0bd276b/schema)