2026-07-17

🔤 "Lane" is now "Status" for the API and MCP

DevStride's app has said Status for a while, but the API, SDK, and MCP server still spoke the older word lane under the hood. This release finishes the rename so the developer surface matches the product.

If you only use the app, nothing changes — this is purely a naming update for programmatic access.

What changed for integrations

• Canonical fields are now status*. laneId → statusId, laneCollectionId → statusCollectionId, laneRank → statusRank, and the related service-desk and rank fields follow the same pattern. The API reference now documents the status names.
• MCP tools are renamed — create_lane → create_status, update_lane → update_status, delete_lane_collection → delete_status_collection, and so on.

Your existing integrations keep working

We didn't hard-break anything. During the migration window:

• Requests may send either spelling — a body with laneId is still accepted (and will remain so for request bodies). New code should send statusId.
• Responses return both the status* and legacy lane* keys, so code that reads laneId keeps working for now.
• The old MCP tool names and /lanes API paths still resolve, marked deprecated.

Please migrate before 31 October 2026

On 2026-10-31, the compatibility layer is removed: responses stop emitting the legacy lane* keys, and the lane-named API paths and MCP tools go away. Before then, update anything that reads lane* from a response, calls a /lanes endpoint, or invokes a lane-named MCP tool to use the status equivalents. Request bodies that send laneId are the exception — those stay permanently accepted, though we recommend switching them too.

Responses carry standard Deprecation and Sunset headers pointing at that date, so you can find affected calls programmatically.