Tarefas recorrentes e repetitivas

O Bordio tem duas maneiras diferentes de fazer uma tarefa se repetir. Elas são mutuamente exclusivas — escolha uma:

• Em um cronograma (recurrence) — a tarefa/evento se repete em datas fixas, por exemplo, toda segunda-feira. Usa um RRULE do iCalendar. Funciona para tarefas e eventos. Abordado primeiro, abaixo.
• Após a conclusão (repeat_on_completion) — uma nova cópia é criada somente quando você fecha a tarefa, com as datas deslocadas para frente. Bom para “faça isto novamente N dias depois de eu terminá-lo”. Apenas tarefas. Veja Repetir após a conclusão.

Em um cronograma (recurrence)

Uma tarefa ou evento pode se repetir em um cronograma — uma tarefa diária, uma reunião semanal, uma revisão mensal. Você cria uma série repetitiva adicionando um objeto recurrence à requisição normal de criação. O resultado é uma série (um template que você referencia pelo seu id), não um monte de cópias.

A recorrência usa o formato RRULE do iCalendar (RFC 5545) — a mesma sintaxe de regra do Google Calendar e do CalDAV. Se você já construiu uma recorrência com alguma biblioteca de calendário, você já sabe como funciona.

Criando um evento recorrente

Adicione recurrence ao POST /scheduled-events. A série é ancorada em start_at.

curl -X POST "https://api.bordio.com/public/v1/scheduled-events" \
  -H "Authorization: Bearer brd_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Team standup",
    "start_at": "2026-07-06T09:00:00Z",
    "end_at": "2026-07-06T09:15:00Z",
    "recurrence": {
      "rule": "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR",
      "until": "2026-12-31"
    }
  }'

Isso cria uma reunião toda segunda, quarta e sexta-feira, de 06 de julho de 2026 até o final do ano.

Criando uma tarefa recorrente

Adicione recurrence ao POST /tasks. A série é ancorada pela date da tarefa (o dia em que a tarefa está agendada) — você deve incluir date, caso contrário a requisição é rejeitada com 422.

curl -X POST "https://api.bordio.com/public/v1/tasks" \
  -H "Authorization: Bearer brd_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Water the plants",
    "project_id": "proj_6594a1b2c3d4e5f6a7b8c9d0",
    "date": "2026-07-06",
    "recurrence": {
      "rule": "RRULE:FREQ=DAILY",
      "until": "2026-08-31"
    }
  }'

O objeto recurrence

Campo	Obrigatório	Descrição
rule	sim	Uma string RRULE pura do iCalendar, por exemplo, RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR.
until	não	Data/data-hora ISO-8601 — o fim inclusivo da série.

Escrevendo o rule

O rule é uma linha RRULE padrão. As partes mais comuns:

• FREQ= — com que frequência: DAILY, WEEKLY, MONTHLY ou YEARLY.
• INTERVAL= — a cada N períodos (por exemplo, INTERVAL=2 com FREQ=WEEKLY = a cada duas semanas). O padrão é 1.
• BYDAY= — dias da semana: MO,TU,WE,TH,FR,SA,SU (use com FREQ=WEEKLY).
• BYMONTHDAY= — dia do mês, por exemplo, BYMONTHDAY=1 (use com FREQ=MONTHLY).

Exemplos:

Objetivo	rule
Todo dia	RRULE:FREQ=DAILY
Todo dia útil	RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
A cada duas segundas-feiras	RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO
No primeiro dia de cada mês	RRULE:FREQ=MONTHLY;BYMONTHDAY=1
Todo ano	RRULE:FREQ=YEARLY

Regras e limites

Para manter as séries válidas e seguras, a API é rigorosa quanto ao rule:

• FREQ é obrigatório e deve ser um dos valores DAILY, WEEKLY, MONTHLY, YEARLY. Frequências sub-diárias (HOURLY, MINUTELY, SECONDLY) são rejeitadas.
• Não inclua DTSTART. O início é derivado do recurso (start_at para eventos, date para tarefas). Um DTSTART no rule é rejeitado.
• Não use COUNT. Delimite a série com o campo until em vez disso.
• INTERVAL, se presente, deve ser um número inteiro positivo (≤ 1000).
• O rule deve ser uma única linha RRULE: (sem RDATE/EXDATE, sem quebras de linha).

Qualquer outra coisa retorna 422 validation_error com o código invalid_recurrence_rule.

Quando ela termina?

Use o campo until para a data de término. Se você omitir until, a série é aberta e se repete indefinidamente.

Nota

Fuso horário: a série de um evento é ancorada no fuso horário do proprietário da chave de API; a série de uma tarefa é ancorada em UTC. Prefira regras em nível de data (por exemplo, “toda segunda-feira”) quando a precisão de fuso horário for importante para você.

Lendo uma série de volta

Recursos recorrentes incluem um objeto recurrence nas respostas; os individuais (não recorrentes) retornam recurrence: null.

{
  "data": {
    "id": "event_6594a1b2c3d4e5f6a7b8c9d0",
    "title": "Team standup",
    "start_at": "2026-07-06T09:00:00.000Z",
    "recurrence": {
      "rule": "RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR",
      "until": "2026-12-31T00:00:00.000Z"
    }
  }
}

O rule retornado é normalizado para a linha RRULE: — o DTSTART interno não é exposto.

Repetir após a conclusão (apenas tarefas)

Em vez de um cronograma fixo, uma tarefa pode gerar uma nova cópia de si mesma quando você a conclui (move-a para um status fechado). Este é um mecanismo diferente do recurrence acima — não há RRULE, e nada é criado até que a tarefa seja de fato fechada. Adicione repeat_on_completion ao POST /tasks:

curl -X POST "https://api.bordio.com/public/v1/tasks" \
  -H "Authorization: Bearer brd_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Change the water filter",
    "project_id": "proj_6594a1b2c3d4e5f6a7b8c9d0",
    "estimated_time_seconds": 1800,
    "repeat_on_completion": {
      "start_date_shift_days": 30,
      "due_date_shift_days": 2,
      "until": "2027-12-31"
    }
  }'

Quando esta tarefa é fechada, o Bordio cria uma nova cópia: mesmo título, projeto, responsáveis, prioridade e subtarefas, com a data de início definida para 30 dias após a data de conclusão e a data de vencimento 2 dias depois disso. A cópia se repete da mesma forma, até que until seja ultrapassado.

Campo	Obrigatório	Descrição
start_date_shift_days	sim	Dias após a conclusão em que a próxima cópia começa. 0 = mesmo dia.
due_date_shift_days	não	Dias após o início da cópia em que sua data de vencimento cai. Omita para não ter data de vencimento.
until	não	Parar de repetir após esta data (ISO-8601). Omita para repetir indefinidamente.

Notas:

• Somente quando fechada. A cópia é criada quando a tarefa passa para um status cujo estado é fechado — não a cada edição.
• Os campos são herdados. Título, descrição, projeto, responsáveis, relatores, prioridade, subtarefas e a estimativa de tempo são transferidos para cada cópia automaticamente; você especifica apenas os deslocamentos de data.
• Mutuamente exclusivo com recurrence. Enviar ambos na mesma tarefa retorna 422.

As respostas incluem um objeto repeat_on_completion (ou null):

{
  "data": {
    "id": "task_6594a1b2c3d4e5f6a7b8c9d0",
    "repeat_on_completion": {
      "start_date_shift_days": 30,
      "due_date_shift_days": 2,
      "until": "2027-12-31T00:00:00.000Z"
    }
  }
}

Série vs. ocorrências

• A série (o template) tem um id simples — task_<id> / event_<id> — o id que você recebe de volta ao criar. Ler, atualizar ou excluir a série aplica-se a toda a série.
• Uma ocorrência individual tem seu próprio id que carrega a data da ocorrência, por exemplo, task_<id>_20260113T090000Z (veja Identificadores). Leia-o de volta a partir da API e use-o exatamente como está para referenciar aquela ocorrência única — nunca o construa você mesmo.

O que é suportado atualmente

• Criar uma tarefa ou evento recorrente.
• Ler, atualizar e excluir tanto uma série quanto uma ocorrência individual pelo seu id.

Ainda não disponível:

• Edições com escopo — semântica de “esta e as seguintes” / “todas”. Uma atualização atualmente afeta o id único que você referencia (a série ou uma ocorrência), não um intervalo escolhido da série.

Esta página será atualizada conforme as edições com escopo forem lançadas.