Have something to say?

Tell us how we could make the product more useful to you.

Completed

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

Mack 21 days ago

1

Completed

Official MCP server for LiteTracker

I'd like to work with LiteTracker stories from AI coding tools (Claude Code, Cursor, etc.) without hand-rolling API calls. An official MCP server would make that a one-line setup instead of a bespoke integration per user. Concretely, the tools I'd want: - Search/list stories with the usual filters (project, state, label, owner, epic) - Read a story with its description, tasks, comments, blockers,and activity - Create and update stories — state, estimate, labels, owner - Add comments Why this should be cheap to build: the v5 REST API already exposes all of the above, so an MCP server is largely a thin typed wrapper over endpoints that exist today. Auth could reuse the existing X-TrackerToken API token. A remote/hosted MCP endpoint (OAuth, like Linear and Sentry ship) would be ideal, but a self-hostable stdio server would already be a big w

vernon@nitidbit.com about 1 month ago

1

Emails from same story should thread/group together

Related to this request: https://litetracker.featurebase.app/p/email-updates-clearer-action-and-story-title Now that I’ve used this feature, I realize because the subject line changes for each type of action, email readers cannot thread the messages. I.e. when someone works on a story, it goes through all the states (started, some comments, finished, delivered). Each email has a different subject. That means 4 or more emails per story. It would be great to have the 4 emails related to the same story be grouped together. That way, reviewing my email, I see the history of the story in one place instead of spread throughout my email inbox. I think this can be achieved by keeping only the story title in the subject line, and have the body of the email mention the action and details.

Winston 5 months ago