Tareas recurrentes y repetidas

Bordio tiene dos formas diferentes en que una tarea puede repetirse. Son mutuamente excluyentes — elige una:

• Según un horario (recurrence) — la tarea/evento se repite en fechas fijas, p. ej. cada lunes. Usa un RRULE de iCalendar. Funciona para tareas y eventos. Se trata primero, más abajo.
• Después de la finalización (repeat_on_completion) — se crea una copia nueva solo cuando cierras la tarea, con las fechas desplazadas hacia adelante. Ideal para “hazlo de nuevo N días después de terminarlo”. Solo tareas. Consulta Repetir después de la finalización.

Según un horario (recurrence)

Una tarea o evento puede repetirse según un horario — una tarea diaria, una reunión semanal, una revisión mensual. Creas una serie repetida añadiendo un objeto recurrence a la solicitud de creación normal. El resultado es una serie (una plantilla que direccionas por su id), no un montón de copias.

La recurrencia usa el formato RRULE de iCalendar (RFC 5545) — la misma sintaxis de reglas que Google Calendar y CalDAV. Si alguna vez has construido una recurrencia con una biblioteca de calendario, ya la conoces.

Crear un evento recurrente

Añade recurrence a POST /scheduled-events. La serie se ancla en 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"
    }
  }'

Esto crea una reunión cada lunes, miércoles y viernes desde el 06 de julio de 2026 hasta fin de año.

Crear una tarea recurrente

Añade recurrence a POST /tasks. La serie se ancla en la date de la tarea (el día en que la tarea está programada) — debes incluir date, de lo contrario la solicitud se rechaza con 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"
    }
  }'

El objeto recurrence

Campo	Obligatorio	Descripción
rule	sí	Una cadena RRULE de iCalendar simple, p. ej. RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR.
until	no	Fecha/fecha-hora ISO-8601 — el final inclusivo de la serie.

Escribir el rule

El rule es una línea RRULE estándar. Las partes más comunes:

• FREQ= — con qué frecuencia: DAILY, WEEKLY, MONTHLY o YEARLY.
• INTERVAL= — cada N períodos (p. ej. INTERVAL=2 con FREQ=WEEKLY = cada dos semanas). El valor predeterminado es 1.
• BYDAY= — días de la semana: MO,TU,WE,TH,FR,SA,SU (úsalo con FREQ=WEEKLY).
• BYMONTHDAY= — día del mes, p. ej. BYMONTHDAY=1 (úsalo con FREQ=MONTHLY).

Ejemplos:

Objetivo	rule
Cada día	RRULE:FREQ=DAILY
Cada día laborable	RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR
Un lunes sí y otro no	RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO
El primero de cada mes	RRULE:FREQ=MONTHLY;BYMONTHDAY=1
Cada año	RRULE:FREQ=YEARLY

Reglas y límites

Para mantener las series válidas y seguras, la API es estricta con el rule:

• FREQ es obligatorio y debe ser uno de DAILY, WEEKLY, MONTHLY, YEARLY. Las frecuencias inferiores a un día (HOURLY, MINUTELY, SECONDLY) se rechazan.
• No incluyas DTSTART. El inicio se deriva del recurso (start_at para eventos, date para tareas). Un DTSTART en el rule se rechaza.
• No uses COUNT. Limita la serie con el campo until en su lugar.
• INTERVAL, si está presente, debe ser un entero positivo (≤ 1000).
• El rule debe ser una única línea RRULE: (sin RDATE/EXDATE, sin saltos de línea).

Cualquier otra cosa devuelve 422 validation_error con el código invalid_recurrence_rule.

¿Cuándo termina?

Usa el campo until para la fecha de finalización. Si omites until, la serie es abierta y se repite indefinidamente.

Nota

Zona horaria: la serie de un evento se ancla en la zona horaria del propietario de la clave de API; la serie de una tarea se ancla en UTC. Prefiere reglas a nivel de fecha (p. ej. “cada lunes”) cuando la precisión de la zona horaria sea importante para ti.

Leer una serie

Los recursos recurrentes incluyen un objeto recurrence en las respuestas; los individuales (no recurrentes) devuelven 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"
    }
  }
}

El rule devuelto está normalizado a la línea RRULE: — el DTSTART interno no se expone.

Repetir después de la finalización (solo tareas)

En lugar de un horario fijo, una tarea puede generar una nueva copia de sí misma cuando la completas (moverla a un estado cerrado). Este es un mecanismo diferente del recurrence anterior — no hay RRULE, y no se crea nada hasta que la tarea se cierra realmente. Añade repeat_on_completion a 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"
    }
  }'

Cuando esta tarea se cierra, Bordio crea una copia nueva: el mismo título, proyecto, asignados, prioridad y subtareas, con su fecha de inicio establecida 30 días después de la fecha de finalización y su fecha de vencimiento 2 días después de esa. La copia se repite de la misma manera, hasta que pasa until.

Campo	Obligatorio	Descripción
start_date_shift_days	sí	Días después de la finalización en que empieza la siguiente copia. 0 = el mismo día.
due_date_shift_days	no	Días después del inicio de la copia en que cae su fecha de vencimiento. Omítelo para no tener fecha de vencimiento.
until	no	Deja de repetir después de esta fecha (ISO-8601). Omítelo para repetir indefinidamente.

Notas:

• Solo cuando se cierra. La copia se crea cuando la tarea pasa a un estado cuya condición es cerrada — no en cada edición.
• Los campos se heredan. El título, la descripción, el proyecto, los asignados, los reporteros, la prioridad, las subtareas y la estimación de tiempo se transfieren automáticamente a cada copia; tú solo especificas los desplazamientos de fecha.
• Mutuamente excluyente con recurrence. Enviar ambos en la misma tarea devuelve 422.

Las respuestas incluyen un objeto repeat_on_completion (o 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"
    }
  }
}

Serie vs. ocurrencias

• La serie (la plantilla) tiene un id simple — task_<id> / event_<id> — el id que recibes al crearla. Leerla, actualizarla o eliminarla se aplica a toda la serie.
• Una ocurrencia individual tiene su propio id que lleva la fecha de la ocurrencia, p. ej. task_<id>_20260113T090000Z (consulta Identificadores). Léelo de vuelta desde la API y úsalo tal cual para direccionar esa única ocurrencia — nunca lo construyas tú mismo.

Qué se admite hoy

• Crear una tarea o evento recurrente.
• Leer, actualizar y eliminar tanto una serie como una ocurrencia individual por su id.

Aún no disponible:

• Ediciones con alcance — semántica de “esta y las siguientes” / “todas”. Actualmente, una actualización afecta al único id que direccionas (la serie, o una ocurrencia), no a un tramo elegido de la serie.

Esta página se actualizará a medida que lleguen las ediciones con alcance.