v5 API: label removal, story reordering and description updates return 200 but don't take effect

We automate our project against the v5 REST API with per-user API tokens, and we've hit three operations the API documents but doesn't appear to implement. In each case the request is accepted rather than rejected, so the failure is silent — a client that checks the status code concludes it worked.

All three are in the Pivotal Tracker v5 spec that help.litetracker.com/api.html mirrors, and all three work correctly in your web UI, so this looks like a gap in the v5 layer rather than an intentional limitation.

1. Removing a label from a story — route not implemented (404)

DELETE /services/v5/projects/{pid}/stories/{sid}/labels/{label_id} -> 404

DELETE /services/v5/projects/{pid}/labels/{label_id} -> 404

DELETE /services/v5/stories/{sid}/labels/{label_id} -> 404

The corresponding reads return 200, so the collections exist and it is the DELETE verb that is missing:

GET /services/v5/projects/{pid}/stories/{sid}/labels -> 200

GET /services/v5/projects/{pid}/labels -> 200

Adding a label works as documented: POST /services/v5/projects/{pid}/stories/{sid}/labels with a nested label body -> 200. The practical effect is that every label our automation applies is permanent — a mistakenly applied label can never be cleared programmatically.

2. Removing a label via a story update — 200, no effect

All of these return HTTP 200 with the label set unchanged on re-read:

PUT /services/v5/projects/{pid}/stories/{sid} with "labels": []

PUT /services/v5/projects/{pid}/stories/{sid} with "label_ids": []

PUT /services/v5/projects/{pid}/stories/{sid} with "labels": [{"id": N}]

PUT /services/v5/projects/{pid}/stories/{sid} with "story": {"labels": []}

3. Reordering a story — 200, no effect

before_id / after_id are documented request-body parameters on the story update endpoint. Every shape we tried returns 200 and leaves the story's position unchanged, verified by re-reading before_id/after_id afterwards:

PUT /services/v5/projects/{pid}/stories/{sid} with "before_id": 12345

PUT /services/v5/projects/{pid}/stories/{sid} with "after_id": 12345

PUT /services/v5/projects/{pid}/stories/{sid} with "position": {"after": "12345"}

PUT /services/v5/projects/{pid}/stories/{sid} with "story": {"position": {"after": "12345"}}

4. Updating a story description — 200, no effect

PUT /services/v5/projects/{pid}/stories/{sid} with a "description" field returns 200; a subsequent GET still shows the previous value.

What we'd ask for, in priority order:

1. Implement DELETE /services/v5/projects/{pid}/stories/{id}/labels/{label_id}

2. Honor before_id / after_id on the v5 story update

3. Honor description on the v5 story update

4. Failing any of the above: return an error status rather than 200. A 4xx with a message would have saved us a great deal of time — a silent 200 is indistinguishable from success to every client library.

Happy to supply exact request/response captures, story ids and timestamps for any of these if that helps reproduce.