Summary
Thanks for maintaining this library! The file/note support has been really useful.
I wanted back/forth integration between my Manta and TickTick, so I reverse-engineered the endpoints behind the device's To-Do feature. It lives on the same viewer.supernote.com host and uses the same authentication as the existing login; the x-access-token header, plus an equipmentno header. It doesn't seem to be documented anywhere publicly, and since this library is currently files-only, I thought it might be a welcome addition.
I have it working end-to-end against a live account, incl. reading, creating, completing, and deleting both tasks and lists, verified round-tripping to the physical device. I'd be glad to open a PR adding it as SNClient methods (plus matching CLI subcommands), reusing the existing login. Raising an issue first to check you're open to it and whether you have preferences on how it should be shaped.
Proposed addition
SNClient methods such as list_task_groups(), list_tasks(sync_token=None), upsert_task(...), delete_task(id), create_group(...), delete_group(id), plus CLI subcommands and tests, all reusing the existing login/session. Happy to send a PR if you're interested. Let me know whether you'd prefer these on SNClient directly or in a separate module, and any naming preferences.
Thanks!
Endpoints
All POST/PUT/DELETE to https://viewer.supernote.com, JSON bodies, with headers x-access-token, equipmentno, and version: 202407.
Reads
POST /api/file/schedule/group/all — task lists ("groups")
request: {"maxResults": null, "pageToken": null}
response: { "scheduleTaskGroup": [ { "taskListId", "userId", "title", "lastModified", "isDeleted", "createTime" } ] }
POST /api/file/schedule/task/all — tasks
request: {"maxResults": "20", "nextSyncToken": null, "nextPageTokens": null}
response: { "nextPageToken", "nextSyncToken", "scheduleTask": [ ...task... ] }
Supports pagination (nextPageToken) and delta sync via nextSyncToken (Google-Tasks style — pass it back to get only changes).
Task object fields: taskId, taskListId (null = inbox/no list), title, detail, status ("needsAction" | "completed"), completedTime (epoch ms), dueTime (epoch ms), importance, isReminderOn ("Y"/"N"), recurrence, isDeleted ("N"/"Y"), lastModified, sort fields, and links (base64-encoded JSON pointing back to the source handwritten note page).
Writes
Create/update list: POST /api/file/schedule/group — { taskListId, userId: null, title, lastModified, createTime, isDeleted: false }
Delete list: DELETE /api/file/schedule/group/{taskListId}
Create/update task (upsert): POST /api/file/schedule/task — full task object → { taskId }
complete = status: "completed" + completedTime; uncomplete = status: "needsAction" + completedTime: 0; move = change taskListId; due date = dueTime (epoch ms)
Delete task: DELETE /api/file/schedule/task/{taskId}
Bulk update: PUT /api/file/schedule/task/list — { "updateScheduleTaskList": [ ...tasks... ] } (the app uses this for reorder/toggle; single upserts via POST .../task also work)
Notes: taskId and taskListId are client-generated 32-hex strings, and the server accepts them on create. userId can be sent as null on create and is filled in server-side.
Summary
Thanks for maintaining this library! The file/note support has been really useful.
I wanted back/forth integration between my Manta and TickTick, so I reverse-engineered the endpoints behind the device's To-Do feature. It lives on the same viewer.supernote.com host and uses the same authentication as the existing login; the x-access-token header, plus an equipmentno header. It doesn't seem to be documented anywhere publicly, and since this library is currently files-only, I thought it might be a welcome addition.
I have it working end-to-end against a live account, incl. reading, creating, completing, and deleting both tasks and lists, verified round-tripping to the physical device. I'd be glad to open a PR adding it as SNClient methods (plus matching CLI subcommands), reusing the existing login. Raising an issue first to check you're open to it and whether you have preferences on how it should be shaped.
Proposed addition
SNClient methods such as list_task_groups(), list_tasks(sync_token=None), upsert_task(...), delete_task(id), create_group(...), delete_group(id), plus CLI subcommands and tests, all reusing the existing login/session. Happy to send a PR if you're interested. Let me know whether you'd prefer these on SNClient directly or in a separate module, and any naming preferences.
Thanks!
Endpoints
All POST/PUT/DELETE to https://viewer.supernote.com, JSON bodies, with headers x-access-token, equipmentno, and version: 202407.
Reads
POST /api/file/schedule/group/all — task lists ("groups")
request: {"maxResults": null, "pageToken": null}
response: { "scheduleTaskGroup": [ { "taskListId", "userId", "title", "lastModified", "isDeleted", "createTime" } ] }
POST /api/file/schedule/task/all — tasks
request: {"maxResults": "20", "nextSyncToken": null, "nextPageTokens": null}
response: { "nextPageToken", "nextSyncToken", "scheduleTask": [ ...task... ] }
Supports pagination (nextPageToken) and delta sync via nextSyncToken (Google-Tasks style — pass it back to get only changes).
Task object fields: taskId, taskListId (null = inbox/no list), title, detail, status ("needsAction" | "completed"), completedTime (epoch ms), dueTime (epoch ms), importance, isReminderOn ("Y"/"N"), recurrence, isDeleted ("N"/"Y"), lastModified, sort fields, and links (base64-encoded JSON pointing back to the source handwritten note page).
Writes
Create/update list: POST /api/file/schedule/group — { taskListId, userId: null, title, lastModified, createTime, isDeleted: false }
Delete list: DELETE /api/file/schedule/group/{taskListId}
Create/update task (upsert): POST /api/file/schedule/task — full task object → { taskId }
complete = status: "completed" + completedTime; uncomplete = status: "needsAction" + completedTime: 0; move = change taskListId; due date = dueTime (epoch ms)
Delete task: DELETE /api/file/schedule/task/{taskId}
Bulk update: PUT /api/file/schedule/task/list — { "updateScheduleTaskList": [ ...tasks... ] } (the app uses this for reorder/toggle; single upserts via POST .../task also work)
Notes: taskId and taskListId are client-generated 32-hex strings, and the server accepts them on create. userId can be sent as null on create and is filled in server-side.