Filtrado de tareas

GET /public/v1/tasks devuelve todas las tareas del ámbito (el mismo conjunto que la vista de tabla del proyecto en la aplicación web) y las acota con filtros de query. Esta página muestra cómo se combinan los filtros y ofrece recetas listas para copiar.

Todos los ejemplos asumen:

BASE="https://api.bordio.com/public/v1"
AUTH='Authorization: Bearer brd_sk_live_...'
PROJECT="proj_6594a1b2c3d4e5f6a7b8c9d1"

Cómo se combinan los filtros

• Parámetros distintos → AND. Cada parámetro añadido acota el resultado.
• Varios valores en un parámetro → OR. Los valores van separados por comas: priority=high,critical coincide con cualquiera de los dos.
• Los parámetros omitidos no restringen nada — sin filtros se devuelven todas las tareas.

Parámetro	Valores	Notas
priority	CSV de lowest, low, medium, high, critical y/o none	none = tareas sin prioridad
task_status_id	CSV de ids task_status_…	Los ids salen de Definitions
state	open | closed	Agrupa los estatus por su estado — no hace falta enumerarlos. Con view=by_task significa “si hay trabajo pendiente”
task_type_id	CSV de ids task_type_…
assignee_id	CSV de ids user_… y/o none	none = tareas sin responsable
date_from	YYYY-MM-DD o datetime ISO-8601	Límite inferior (inclusive) del día para el que está programada la tarea — el campo date, no la fecha límite
date_to	YYYY-MM-DD o datetime ISO-8601	Límite superior del mismo día. Cualquiera de los dos límites ordena la lista por fecha, de la más antigua a la más reciente
due_date_from	YYYY-MM-DD o datetime ISO-8601	Límite inferior del rango de fecha límite (inclusive)
due_date_to	YYYY-MM-DD o datetime ISO-8601	Límite superior del rango de fecha límite (inclusive)
due_date	none	Solo tareas sin fecha límite; incompatible con los límites del rango
tag_id	CSV de ids tag_…	Coinciden las tareas con cualquiera de las etiquetas
view	by_task | by_date	Cambia qué cuenta como un registro — consulta Tareas recurrentes en una lista
closed_since	YYYY-MM-DD o datetime ISO-8601	Solo tareas completadas en ese momento o después; las más recientes primero

Recetas

Solo tareas sin responsable

El valor especial none coincide con tareas que no tienen responsable:

curl "$BASE/tasks?project_id=$PROJECT&assignee_id=none" -H "$AUTH"

Tareas de una persona concreta — o de nadie

none puede mezclarse con ids de usuarios en el mismo CSV; dentro de un parámetro los valores se combinan con OR:

curl "$BASE/tasks?project_id=$PROJECT&assignee_id=user_6594a1b2c3d4e5f6a7b8c9d1,none" -H "$AUTH"

Tareas sin prioridad — o con prioridad baja

La prioridad es opcional, así que priority acepta el valor especial none para tareas donde no está definida. Como cualquier valor CSV, se combina con OR — «sin prioridad o low» es un solo parámetro:

curl "$BASE/tasks?project_id=$PROJECT&priority=none,low" -H "$AUTH"

Tareas abiertas con prioridad alta o crítica

curl "$BASE/tasks?project_id=$PROJECT&state=open&priority=high,critical" -H "$AUTH"

state es la forma más sencilla de separar el trabajo abierto del cerrado. Si necesitas estatus concretos («En progreso» pero no «Nueva»), usa task_status_id con ids de los endpoints de definitions.

Tareas con fecha límite en julio

Ambos límites son inclusivos; los valores de solo fecha se expanden al inicio / fin de ese día (UTC):

curl "$BASE/tasks?project_id=$PROJECT&due_date_from=2026-07-01&due_date_to=2026-07-31" -H "$AUTH"

También puedes pasar un solo límite — por ejemplo, todo lo que vence desde hoy (due_date_from solo), o una vista de «vencidas» — tareas abiertas cuyo plazo ya pasó:

curl "$BASE/tasks?project_id=$PROJECT&state=open&due_date_to=2026-07-17" -H "$AUTH"

Tareas sin fecha límite

Un rango nunca puede coincidir con una tarea sin fecha límite, por eso es un filtro aparte:

curl "$BASE/tasks?project_id=$PROJECT&due_date=none" -H "$AUTH"

Tareas con cualquiera de las etiquetas dadas

curl "$BASE/tasks?project_id=$PROJECT&tag_id=tag_65dcc9c66f2e4e001ab18859,tag_66446ff2dc01cb59f6cbf7a6" -H "$AUTH"

Todo combinado

Abiertas, de prioridad alta, sin responsable, con fecha límite este mes:

curl "$BASE/tasks?project_id=$PROJECT&state=open&priority=high&assignee_id=none&due_date_from=2026-07-01&due_date_to=2026-07-31" -H "$AUTH"

Los filtros se componen con la paginación como siempre — limit y cursor se aplican al resultado filtrado (ver Convenciones).

Tareas recurrentes en una lista

Por defecto, una lista devuelve tus tareas puntuales más las ocurrencias individuales de las recurrentes que ya existen: las que alguien editó, completó o reprogramó. Por eso una misma tarea recurrente puede aparecer como varias filas, y una ocurrencia que nadie ha tocado no aparece en absoluto.

Pasa view=by_task para listar tareas: una tarea recurrente vuelve como una sola fila con su regla y la ocurrencia de la que toca ocuparse, y sus ocurrencias no se listan por separado.

curl "$BASE/tasks?project_id=$PROJECT&view=by_task" -H "$AUTH"

La respuesta añade kind, series_id, series_chain_id, recurrence_summary y current_occurrence; consulta Tareas recurrentes. Sin view el conjunto de registros no cambia, así que las integraciones existentes siguen funcionando — pero las nuevas deberían pasarlo de forma explícita.

Qué ocurre en un periodo

Pasa view=by_date con un rango de fechas para listar ocurrencias: cada día en el que cae una tarea recurrente es su propia fila, junto a las tareas puntuales programadas en esos días.

curl "$BASE/tasks?project_id=$PROJECT&view=by_date&date_from=2026-09-01&date_to=2026-09-30" -H "$AUTH"

Aquí el rango es obligatorio y no puede superar los 31 días, los resultados van desde el inicio del rango y closed_since no se combina con esta vista (400). Detalles y lista completa de reglas: Listar ocurrencias día a día.

Qué hacer ahora

curl "$BASE/tasks?project_id=$PROJECT&view=by_task&state=open" -H "$AUTH"

En esta vista, state responde a “si hay trabajo pendiente”: una tarea puntual por su propio estatus, una recurrente por sus ocurrencias — abierta mientras quede una abierta, cerrada cuando no queda ninguna. Una tarea recurrente que se quedó sin ocurrencias desaparece de la lista aunque el estatus con el que arrancan sus ocurrencias sea un “To do” perfectamente normal.

Qué se completó recientemente

curl "$BASE/tasks?project_id=$PROJECT&closed_since=2026-07-28" -H "$AUTH"

Lo completado es otra pregunta, así que es otra petición. Cada ocurrencia completada es su propio registro — eso significa “hicimos el standup el martes” —, por lo que esta lista no se combina con view=by_task: hacerlo devuelve 400 validation_error. El orden es por momento de finalización, las más recientes primero, y la paginación es la habitual.

closed_since también rechaza state=open con 400, por la misma razón: la petición se contradice a sí misma, y una página vacía se leería como “no se completó nada” en lugar de “has pedido algo imposible”.

due_date_from / due_date_to / due_date — ¿por qué tres parámetros?

Responden a dos preguntas distintas:

• due_date_from / due_date_to seleccionan tareas cuya fecha límite cae en un rango. Usa un límite solo o ambos.
• due_date=none selecciona tareas que no tienen fecha límite. Ningún rango puede expresar «el campo está vacío», por eso es un parámetro aparte y no un valor mágico del rango.

Como «sin fecha límite» y «fecha límite en un rango» son mutuamente excluyentes, combinar due_date=none con cualquier límite devuelve 400 validation_error.

Qué errores esperar

• Un valor mal formado (prioridad desconocida, id con formato inválido, no-fecha) → 400 validation_error.
• Un id bien formado que no coincide con nada (etiqueta de otro workspace, estatus eliminado) → no es un error: simplemente no coincide ninguna tarea y recibes una página vacía.
• La excepción es project_id: un proyecto fuera del alcance de tu clave → 404 not_found_error.