Hey @Richard_Sather that’s great news! I’m really glad I could help
On the docs question: the endpoint used here lives under the Tasks API, not Custom types. Setting a task’s status is done via PUT /tasks/{task_gid} that’s why you’ll find it documented on the Update a task page and that’s where my earlier confusion came from thinking your intent was to modify the options themselves
I noticed that custom_type and custom_type_status_option are now listed as possible keys in the data object for creating a task.
However, when I try to use them, I get a 403 error saying The custom type feature is not supported on this route .
Can we assume that this is still in the works so that it’ll be possible to create custom task types with a single API call rather than creating a regular task first and then using the PUT endpoint to update its type?
Hi @Layfando , good catch! At the moment, the custom_type and custom_type_status_option properties are conciosly gated on POST (task creation) and are only supported via PUT (task update).
The behavior is expected to be aligned so that creating a custom type task can be done seamlessly, but there’s still some dependency work to complete before that can happen. Until then, the supported pattern is to create the task via POST /tasks (without custom_type fields) and then update it via PUT /tasks/{task_gid} with intended custom_type / custom_type_status_option.
Perfect, that’s what I figured, looking forward to it!
Love the work you’re doing with custom types, it’s super helpful for our project setup!
Btw, it seems like the releases around custom types don’t quite get the spotlight they deserve … missed global custom types until (re-)reading this thread