Identificadores

Todo id de recurso é uma string no formato <prefix>_<value>. O prefixo nomeia o tipo do recurso, então passar um id do tipo errado é rejeitado com 422 validation_error (invalid_request) em vez de resolver silenciosamente o recurso errado.

Prefixos

Prefixo	Recurso	Exemplo
`task_`	tarefa	`task_6594a1b2c3d4e5f6a7b8c9d0`
`subtask_`	subtarefa	composto — veja abaixo
`time_log_`	bloco de tempo (time log)	composto — veja abaixo
`event_`	evento agendado	`event_6594a1b2c3d4e5f6a7b8c9e0`
`proj_`	projeto	`proj_6594a1b2c3d4e5f6a7b8c9a0`
`user_`	membro do espaço de trabalho	`user_6594a1b2c3d4e5f6a7b8c9b0`
`tag_`	tag	`tag_6594a1b2c3d4e5f6a7b8c9c0`
`task_status_`	status de tarefa	`task_status_6594a1b2c3d4e5f6a7b8c9d2`
`task_type_`	tipo de tarefa	`task_type_6594a1b2c3d4e5f6a7b8c9d3`
`event_type_`	tipo de evento	`event_type_6594a1b2c3d4e5f6a7b8c9d4`
`proj_status_`	status de projeto	`proj_status_6594a1b2c3d4e5f6a7b8c9d5`
`cf_`	campo personalizado	`cf_6594a1b2c3d4e5f6a7b8c9d6`
`cf_option_`	opção de campo personalizado	`cf_option_6594a1b2c3d4e5f6a7b8c9d7`
`attachment_`	anexo	`attachment_6594a1b2c3d4e5f6a7b8c9d8`
`chat_message_`	mensagem de chat	`chat_message_6594a1b2c3d4e5f6a7b8c9d9`

A maioria dos recursos usa o formato simples <prefix>_<value>. Duas coisas adicionam partes extras: subtarefas/blocos de tempo (time logs) (que codificam sua tarefa pai) e ocorrências recorrentes (que anexam uma data).

Ids compostos: subtarefas e blocos de tempo (time logs)

Uma subtarefa ou bloco de tempo (time log) é sempre endereçado junto com sua tarefa pai, então seu id carrega ambos — primeiro o filho, depois a tarefa pai:

subtask_<child>_<parent task>
time_log_<child>_<parent task>

Para uma tarefa task_6594a1b2c3d4e5f6a7b8c9d0:

Recurso	Exemplo de id
subtarefa	`subtask_6594a1b2c3d4e5f6a7b8c9d1_6594a1b2c3d4e5f6a7b8c9d0`
bloco de tempo (time log)	`time_log_6594a1b2c3d4e5f6a7b8c9d2_6594a1b2c3d4e5f6a7b8c9d0`

O trecho final 6594a1b2c3d4e5f6a7b8c9d0 é o valor da tarefa pai. Ainda é uma única string opaca — você passa a coisa inteira como um único id, não a monta a partir de partes.

Tarefas e eventos recorrentes

Uma série recorrente tem um id simples — task_<value> ou event_<value> — que endereça a série inteira (lê-la, editar a regra, excluir todas as ocorrências).

Uma única ocorrência dessa série é endereçada anexando o horário de início da ocorrência (UTC, YYYYMMDDTHHMMSSZ):

task_<series>_<date>          e.g. task_6594a1b2c3d4e5f6a7b8c9d0_20260113T090000Z
event_<series>_<date>         e.g. event_6594a1b2c3d4e5f6a7b8c9e0_20260113T090000Z

Quando você edita esta ocorrência e todas as seguintes, a API pode devolver um id de série marcado com um R antes da data — esta é uma série “daqui em diante” distinta, ainda opaca:

task_6594a1b2c3d4e5f6a7b8c9d0_R20260113T090000Z

Qualquer coisa que pertença a uma ocorrência carrega o mesmo sufixo de data após a parte composta — então uma subtarefa ou bloco de tempo (time log) de uma ocorrência tem esta aparência:

subtask_6594a1b2c3d4e5f6a7b8c9d1_6594a1b2c3d4e5f6a7b8c9d0_20260113T090000Z
time_log_6594a1b2c3d4e5f6a7b8c9d2_6594a1b2c3d4e5f6a7b8c9d0_20260113T090000Z

Qual id usar

Você quer…	Use
Ler/atualizar/excluir a série inteira	o id simples da série — `task_<series>`
Agir sobre uma ocorrência	o id da ocorrência — `task_<series>_<date>`
Agir sobre uma ocorrência e todas as seguintes	o id marcado com `R` que a API retornou

Por que isso importa na prática

Como você trata todo id como opaco, os mesmos endpoints funcionam independentemente do formato. GET /tasks/{id} aceita um id de tarefa simples, um id de ocorrência ou um id de série marcado com R — você não trata o formato como caso especial, e não precisa saber qual deles está em mãos. Leia os ids das respostas, armazene-os inteiros e envie-os de volta exatamente como recebidos.