Todos.Update uses wrong endpoint - missing /buckets/{projectID}/ segment

[pravashkarki]

Description

TodosService.Update() in pkg/basecamp/todos.go:407 calls:

s.client.parent.gen.UpdateTodoWithBodyWithResponse(ctx, s.client.accountID, todoID, ...)

This sends PUT /{accountID}/todos/{todoID}.json instead of the documented PUT /buckets/{projectID}/todos/{todoID}.json.

Impact

The shorthand endpoint accepts the request (returns 200) but silently ignores the description field. Other fields like content and due_on appear to work, making this hard to diagnose.

This affects the CLI (basecamp todos update --description) and any SDK consumer trying to set a todo's description.

Related CLI issue: basecamp/basecamp-cli#422

Expected

Todos.Update() should use the project-scoped endpoint: PUT /buckets/{projectID}/todos/{todoID}.json

Version

basecamp-sdk/go v0.7.3

[pravashkarki]

Traced this to the Smithy model in spec/basecamp.smithy:

@http(method: "PUT", uri: "/{accountId}/todos/{todoId}")
operation UpdateTodo {

The SDK correctly implements the spec. The issue is that the BC3 API's shorthand endpoint (PUT /{accountId}/todos/{todoId}) silently ignores the description field, while the project-scoped endpoint (PUT /{accountId}/buckets/{bucketId}/todos/{todoId}.json) handles it correctly.

Two possible fixes:

1. API-side: Make the shorthand endpoint respect the description field (consistent behavior)
2. Spec-side: Change the URI to /{accountId}/buckets/{bucketId}/todos/{todoId} and add bucketId to UpdateTodoInput

Option 2 would also require the CLI and SDK callers to pass the project/bucket ID, which is a breaking change but aligns with the documented BC3 API.

[schmunk42]

This is really annoying when working with AI agents and CLI.

[robzolkos]

Thanks for the detailed report and for tracing this through the CLI and SDK. I can see why this looked like an SDK endpoint bug: the CLI returned success, the description did not change, and a manual bucket-scoped API call appeared to work.

After checking this against the current Basecamp API docs, routes, and tests, the SDK is using the documented canonical endpoint:

PUT /{account_id}/todos/{todo_id}.json

The bucket-scoped form:

PUT /{account_id}/buckets/{bucket_id}/todos/{todo_id}.json

is still supported, but it is documented as a legacy route rather than the route new integrations should prefer.

The issue appears to be in the CLI update behavior, not the SDK route. Todo updates are replacement-style: callers need to send the existing fields they want to preserve, and content is required. A description-only update from the CLI can therefore look like a successful no-op, while a title-only update can unintentionally clear omitted fields such as description.

That lines up with the related CLI reports around todos update --description, todos update --due, and title-only updates wiping descriptions. The fix belongs in basecamp-cli: the CLI should fetch the existing todo, merge in the requested changes, and send a complete update payload. There are already PRs open that address this behavior, including basecamp/basecamp-cli#413.

There may also be room for an API-side improvement so missing required fields return a clearer validation error instead of looking like a successful no-op. But changing the SDK endpoint to the bucket-scoped route would move it away from the current API docs and introduce a breaking signature change without addressing the real update semantics.

The right follow-up is in the CLI update path, where fixes are already in progress.

[jeremy]

🤖 Posted with agent assistance by @jeremy.

Closing as misdiagnosed — the endpoint was never wrong, and the fix is landing under #372 rather than a route switch.

Evidence:

1. The flat route is canonical. The maintainer disposition above (2026-06-10) confirms PUT /{account_id}/todos/{todo_id}.json is the documented canonical endpoint and labels the bucket-scoped form legacy.
2. BC3's API tests prove the flat route persists description when required content is present (bc3 test/api/todos_controller_api_test.rb, "update todo via unscoped route"), with parallel coverage of the bucket route behaving identically.
3. The observed "description dropped" was the sparse body, not the route. Todo updates are replacement-style with content required: a description-only PUT without content looks like a successful no-op, and a title-only PUT clears omitted fields. That's exactly what the CLI reports (todos update --description silently fails (wrong API endpoint) basecamp-cli#422) experienced.

The real defect — SDKs presenting a partial-update surface over a full-replace endpoint — is fixed by #372: the spec renames the operation to ReplaceTodo with content required, and every SDK gains merge-safe update, read-modify-write edit, and verbatim replace, all on the canonical flat route.