Work item's milestone is not exposed by the Work Items API (cycle_id is)

Summary

A work item's milestone is not returned by the Work Items API. cycle_id is returned, but there is no equivalent milestone field on any work-item endpoint, and no expand value produces one. The only way to learn which milestone a work item belongs to is to list every milestone in the project and then list each one's work items, building the reverse mapping yourself.

Steps to reproduce

Take a work item that is on a milestone (confirmed via GET /milestones/{milestone_id}/work-items/, which does return it), then:

GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/
GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/?expand=state,milestone,milestones
GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/properties/

None of the three responses contains any key matching milestone. The same response does contain cycle_id.

Expected

A milestone_id on the work item, alongside cycle_id, and ideally an ?expand=milestone giving the milestone object (title and target_date).

Why it matters

We sync Plane work items into our own support portal and show clients the release date their fix is scheduled for. That date lives on the milestone. Because the API will not tell us which milestone a work item is on, we cannot read it at all on demand, and we cannot backfill existing tickets without walking every milestone in the project and inverting the relationship.

We currently get the milestone only because the v2 webhook happens to carry it on a milestone_issue event. That means the value is only ever knowable at the moment it changes. Anything that missed the webhook, or predates it, is unrecoverable through normal means.

Related

This is the same shape of problem as a few other reports: data that exists in the product but is either absent from the work-item response or shaped differently depending on which endpoint you ask.

• #8654 custom properties absent from the work-items response
• #9534 ?expand=state returning a bare UUID
• #9594 labels as UUIDs in list responses but objects in single-item responses

Start by tracing the work-item detail, expanded, and properties endpoints shown in the reproduction, then compare them with GET /milestones/{milestone_id}/work-items/. The work is done when work-item responses expose milestone_id consistently and the requested milestone expansion returns its title and target_date, with coverage for existing and missing milestones.