Public API

I'd like to use DraftsApp (or other deeplink crafting) to add tasks, notes & ambiguous markdown to taskade. This is definitely a power user feature so I'd be okay with using long node_ids and a number of required querystring parameters Right now I'm aware taskade:// will open the app on iOS, iPad. My request is to include documentation on this for power users (with warning its likely to change if it's not a finalized or public API) for taskade://paths... and/or taskade://...?args... I could include in a querystring to construct a URI that would then add what I passed to it into taskade they be documented. If it doesn't exist beyond taskade:// being registered (to just open the app). Some thoughts I have which would be nifty are: create a project providing markdown in a querystring paramater as a blob (no limit to how much text a querystring can contain) taskade://new?markdown=... or with a specific title taskade://new?title=My%20Project&markdown=... or with tasks/bullets/paragraphs taskade://new?title=My%20Project&tasks=One%0ATwo%0AThird%20Task&bullets=One%0ATwo%0AThree&paragraphs=%0A%0AParagraph%20with%20two%20new%20lines%20above%20and%20below%0A%0A add task/bullets/paragraph/markdown as a child to a specific node_id with an optional querystring paramter to indicate whether it should be top or bottom (defaults to bottom if not present) taskade://add/<node_id>?top&tasks=One%0ATwo%0AThird%20Task&bullets=One%0ATwo%0AThree&paragraphs=%0A%0AParagraph%20with%20two%20new%20lines%20above%20and%20below%0A%0A add task/bullets/paragraph/markdown as a sibling(s) to a specific node_id , with an optional querystring parameter to indicate whether it should be above or below taskade://add/sibling/<node_id>?above&tasks=One%0ATwo%0AThird%20Task&bullets=One%0ATwo%0AThree&paragraphs=%0A%0AParagraph%20with%20two%20new%20lines%20above%20and%20below%0A%0A Adding things is sufficient enough for me, while I'm assuming if I provide a specific node_id I don't need to say which project/block_title it's under.

I'd like to do the following via API: Prompt Agent and Receive Response Run Agent Command Add or Remove from Agent Knowledge Edit Agent Instructions Create/Edit/Delete Agent Commands

when doing a POST to /projects/{projectId}/tasks/ the body must contain a projectId and a placement or a HTTP: 500 is returned, which I deduce is a serialization error, expecting something that's not there, which I'll walk you through: Sending a request that's like what's documented at https://developers.taskade.com/docs/api/tasks/create : curl -X 'POST' \ 'https://www.taskade.com/api/v1/projects/REDACTED/tasks/' \ -H 'accept: application/json' \ -H 'Authorization: Bearer REDACTED' \ -H 'Content-Type: application/json' \ -d '{ "tasks": [ { "contentType": "text/markdown", "content": "test 4" } ] }' returning: { "statusCode": 500, "code": "FST_ERR_FAILED_ERROR_SERIALIZATION", "message": "Failed to serialize an error. Error: [\n {\n \"code\": \"invalid_literal\",\n \"expected\": false,\n \"path\": [\n \"ok\"\n ],\n \"message\": \"Invalid literal value, expected false\"\n },\n {\n \"code\": \"invalid_type\",\n \"expected\": \"string\",\n \"received\": \"undefined\",\n \"path\": [\n \"code\"\n ],\n \"message\": \"Required\"\n },\n {\n \"code\": \"invalid_type\",\n \"expected\": \"string\",\n \"received\": \"undefined\",\n \"path\": [\n \"statusMessage\"\n ],\n \"message\": \"Required\"\n }\n]. Original error: [\n {\n \"code\": \"invalid_type\",\n \"expected\": \"string\",\n \"received\": \"undefined\",\n \"path\": [\n \"message\"\n ],\n \"message\": \"Required\"\n },\n {\n \"code\": \"invalid_type\",\n \"expected\": \"string\",\n \"received\": \"undefined\",\n \"path\": [\n \"statusMessage\"\n ],\n \"message\": \"Required\"\n }\n]" } the expanded .message : "Failed to serialize an error. Error: [ { "code": "invalid_literal", "expected": false, "path": [ "ok" ], "message": "Invalid literal value, expected false" }, { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ "code" ], "message": "Required" }, { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ "statusMessage" ], "message": "Required" } ]. Original error: [ { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ "message" ], "message": "Required" }, { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ "statusMessage" ], "message": "Required" } ]" I was looking at the schema, trying to understand why this would be the case and I'm not sure how concrete it is, but I thought maybe the allOf was a requirement, meaning it necessarily needed the projectId and placement fields to be included (see images, which are from https://developers.taskade.com/docs/api/tasks/create ) a successful request is like: curl -X 'POST' \ 'https://www.taskade.com/api/v1/projects/REDACTED/tasks/' \ -H 'accept: application/json' \ -H 'Authorization: Bearer REDACTED' \ -H 'Content-Type: application/json' \ -d '{ "tasks": [ { "taskId": "REDACTED", "placement": "afterbegin", "contentType": "text/markdown", "content": "test 4" } ] }' Maybe a potential bug, with the raw schema showing an allOf , anyOf logic requiring something different than what is documented. This is a presumption of mine, I presume this is from code generation and the schema logic is exposing what the serializer is actually expecting - a reference to "code": "FST_ERR_FAILED_ERROR_SERIALIZATION" .

Would like to have a PUT /{taskId}/content (or eventually a PATCH /{taskId}/ ) route be available for updating atomically the task content. I understand there's a PUT pattern now for DATE s and ASSIGNEES , I think that would be fine pattern to adopting too, with a PUT /projects/{projectId}/tasks/{taskId}/content to update the content directly. To expand on mentioning PATCH routes, I think a PATCH would work at the root path of /projects/{projectId}/tasks/{taskId}/ , without any path indicating what we're updating on the task in the body ( content , assignee , [attachments] ...), and using what I see the API has now as the pattern going forward. I see the pattern as "PUT == create or update a /{piece} of item" (uses selection of item at .../collection/item/piece/ ) POST == create the whole item (uses root of item at .../collection/item/ ) PATCH == update a part of the already-created item (uses root of item at .../collection/item/ )

An additional route for a PUT /projects/{projectId}/tasks/{taskId}/note for adding a NOTE attachment to a task. This is hopefully a smaller request than implementing all items that can appear in the ➕ menu, assuming NOTE s (added with Shift + Enter) are like attachments too. This also builds off my request for editing a task body. I would be able to edit this note directly by replacing it. https://www.taskade.com/feedback/public-api/p/update-taskcontent-route I would also want to be able to GET /projects/{projectId}/tasks/{taskId}/note . For reading a task.note .

A small quirk between documentation and an endpoint I was playing with, I didn't do a deep investigation to see if this difference occurs for all DELETE routes The DELETE /projects/{projectId}/tasks/{taskId} doesn't return the expanded item in response, it'll return { "ok": true, "item": null } screenshots are of the expected response shape from the OpenAPI Playground at https://www.taskade.com/api/documentation/static/index.html#/Task/taskDelete and https://developers.taskade.com/docs/api/tasks gitbook

doing a POST /projects with body of { "folderId": "REDACTED", "contentType": "text/markdown", "content": "910pm-20231022" } Will successfully create a new project, however it will be named "Untitled" with one task added with the content provided. The response is HTTP: 200 with body: { "ok": true, "item": { "id": "REDACTED" } } For more context, here's the GET /projects/{projectId}/tasks , which shows how the project's title is not filled in and the project has one task with the content provided in the previous request: { "ok": true, "items": [ { "id": "REDACTED_FIRST_TASK_ID", "text": "" }, { "id": "REDACTED", "text": "910pm-20231022", "parentId": "REDACTED_FIRST_TASK_ID" } ] } Screenshot is the new project created.

Add a route for grabbing a task due date, a GET /projects/{projectId}/tasks/{taskId}/date to add to the DELETE & PUT actions currently available for that route. Eventually including it in the GET /projects/{projectId}/tasks collection response and a GET /projects/projectId}/tasks/{taskId} item response would be nice too.

Figure I'd mention another quirk, although in practice it wouldn't matter that much While PUT /projects/{projectId}/tasks/{taskId}/date accepts a JSON body with two keys of start and stop , they're read differently. You must include seconds in a start.time , like 16:12:00 , while an end.time doesn't care, and both 18:12 and 18:12:00 will be parsed correctly, and be the same time. Another quirk is that the GitBook docs don't explain what format each field is expecting (1st screenshot) https://developers.taskade.com/docs/api/tasks/date While the OpenAPI playground page shows the expected format, however it's got a few problems (2nd screenshot) and body snippet copied below https://www.taskade.com/api/documentation/static/index.html#/Task/taskPutDate The first part of the quirk of the OpenAPI example body sometimes shows seconds on the end.time key, but it only fails if it's not included on the start.time key. The other is that these dates are wayyyy off into the future. Other times it will show seconds on start.time , the values are faked, or mocked which makes sense. It's a superficial issue, but I figured I include it since I wasn't sure if I was supposed to use some other calendar at first, when I started to get errors for not including seconds in start.time :P from the OpenAPI Playground Example Body - different than the screenshot, and sometimes it will render a start.time with seconds, it's random: { "start": { "date": "8692-82-26", "time": "23:44", "timezone": "string" }, "end": { "date": "5809-32-83", "time": "21:56:45", "timezone": "string" } } The error when not including :SS on start.time is the 3rd screenshot and is like: HTTP 500 { "ok": false }

Not sure if this is necessarily required. I don't have a use case other than hiding them or not listing them with my toy CLI. (Most of my use cases only require a single project and a place on the project after::taskId at the moment.) If I were to list all workspaces / folders it may be useful to know if the folder is Archived, so I skip fetching them and displaying them to the user for selecting from their familiar taxonomy of Workspace -> Folder -> Project.