Changelog de la API

Los cambios aditivos a la API pública de Dailybot aterrizan continuamente. Los cambios rompedores viajan en un prefijo de URL nuevo (/v2/) con un sunset mínimo de seis meses sobre la versión previa. Esta página es el log en vivo — agrégala a tu lector y nunca tendrás que adivinar cuándo apareció un endpoint nuevo.

Qué califica como cambio

Logueamos cuatro categorías: Añadido (endpoint nuevo, campo nuevo en una respuesta, query param nuevo), Cambiado (comportamiento de un endpoint existente cambió de forma compatible), Deprecado (feature que planeamos remover, siempre con la fecha más temprana de remoción), y Removido (remoción rompedora, siempre anunciada ≥ 6 meses antes como Deprecado). No logueamos cambios puramente internos.

Entradas

2026-09-30 · Agregado — Notificaciones, resumen personal y reportes programados (Plan Beta)

• Catálogo de notificaciones e interruptores personales — GET /v1/plan/notifications/catalog/ lista todos los tipos; GET / PUT /v1/plan/me/notifications/ leen y cambian tus propios interruptores por tipo y canal (DM y/o correo), y adónde van los DM. Nunca recibes notificaciones de tus propias acciones.
• Rutas de canal — los administradores de la organización crean rutas (/v1/plan/notification-routes/) que publican los tipos de la organización que elijan (una tarea completada, una actualización de proyecto, un cambio de líder…) en un canal de chat, para todo el espacio de trabajo o para algunos tableros o proyectos. Cada ruta tiene un registro de entregas y un envío de prueba con ?dry_run=true.
• Reportes programados — /v1/plan/reports/ programa un reporte diario, de inicio o de fin de semana los días y a la hora local que elijas, a un canal y/o por correo, con vista previa sobre datos reales, registro de ejecuciones y envío de prueba.
• Resumen diario personal — GET / PUT /v1/plan/me/briefing/, más preview/ y send-test/: en qué deberías trabajar hoy, por mensaje directo y/o correo.
• Además — GET /v1/plan/channels/ para buscar los canales donde pueden publicar rutas y reportes; adjuntos de tablero (/v1/plan/boards/{board_id}/attachments/); renombrar adjuntos de tareas, comentarios, proyectos y objetivos; quién reaccionó a un comentario o a una actualización de proyecto, y reacciones en actualizaciones de proyecto.

2026-09-30 · Cambiado — Dailybot Plan: ruta base /v1/plan/ (Plan Beta)

• Ruta base. Todos los endpoints de Dailybot Plan viven bajo /v1/plan/…, con los scopes tasks:read / tasks:write / tasks:admin y los eventos de webhook tasks.*. No existe otro prefijo.
• CLI 4.0.0 — todos los comandos de Plan viven bajo dailybot plan <tasks|task|board|project|goal> …. Nuevos grupos tasks notifications|routes|reports|briefing|channels y filtros por proyecto e hito en tasks timeline. Índice de comandos: CLI de Dailybot para Plan.

2026-09-25 · Agregado — Filtro de menciones en la bandeja (Plan Beta)

• Menciones — GET /v1/plan/inbox/?mentioned=true conserva solo los eventos en los que alguien te mencionó, con count y paginación exactos. Se combina con type (Y).
• Insignias por pestaña — GET /v1/plan/inbox/unread-count/ acepta los mismos filtros mentioned y type, así la insignia de cada pestaña cuenta exactamente sus filas. Sin parámetros la respuesta no cambia. Ambos endpoints rechazan parámetros no declarados con 400 invalid_filter_value.

2026-09-29 · Cambiado — una API key personal actúa como su persona en todo Plan (Plan Beta)

• Una API key personal es su persona. Ve lo que ve la persona (incluidos los tableros privados a los que pertenece), me es la persona, y las escrituras se registran como la persona. Puede hacer todo lo que la persona puede hacer en cada endpoint de Plan, incluidos proyectos, tableros, columnas, objetivos, hitos, miembros, participantes, silenciar, vistas guardadas y adjuntos. No hace falta un rol de administrador de la organización ni otorgar scopes; los scopes tasks:* explícitos de la key son un techo que eligió la persona (tasks:write cubre las operaciones de administración, tasks:read es solo lectura).
• Las keys de agente y de la organización no cambian. Nunca actúan como una persona: 403 insufficient_scope en los endpoints que requieren una persona, 400 actor_required en owner=me. Los invitados siguen rechazados con 403 guest_not_allowed, con una key o una sesión.
• Los tableros ganan effective_visibility (org o members): un tablero dentro de un proyecto members se lee members. Los objetos privados son 404 not found para quien no tiene un grant.
• CLI 3.19.0: --agent-name / DAILYBOT_AGENT_NAME, task brief, y un token de login ligado al host de la API que lo emitió. 3.19.1: guía más clara de invalid_agent_attribution. 3.20.0: una API key personal puede hacer todo lo que su persona puede hacer en Plan, y se corrigió task labels. 3.21.0: comandos de hitos y actualizaciones: project milestone-attach, milestone-attachments, milestone-attachment get|rename|delete, milestone-restore, update-get, update-edit, update-delete, update-attach, update-attachments y update-attachment get|rename|delete. 3.22.0: el CLI cubre todas las operaciones de Plan en vivo: task comment-react|comment-unreact, board label update|delete, board visit, tasks recents, tasks attachments-resolve y task comment --reply-to <uuid-del-comentario>. También refuerza el cierre de sesión (logout revoca todas las sesiones) y los nombres de archivos descargados. Consulta Autenticación para Plan y Atribución de agente.

2026-09-29 · Agregado — Hitos y actualizaciones de proyecto (Plan Beta)

• Hitos y actualizaciones de proyecto — nuevo POST …/milestones/{milestone_id}/restore/; adjuntos en hitos y en actualizaciones de proyecto (GET|POST(multipart, hasta 5 MiB) …/attachments/, GET|PATCH(renombrar)|DELETE …/attachments/{attachment_id}/ y GET …/attachments/{attachment_id}/content/); y GET|PATCH|DELETE …/updates/{update_id}/. Referencia los archivos con marcadores attachment:{uuid}. Los hitos ganan attachment_count; las actualizaciones llevan executed_by_agent, provenance, edited_at y attachments. Solo quien escribió una actualización la edita o le adjunta archivos (403 update_not_author, un código nuevo); la persona autora o un administrador de la organización la elimina. Envía agent_name para coescribir una actualización con un agente.

2026-09-29 · Agregado — Atribución de agente en Plan (Plan Beta)

• Nombra al agente en una escritura — todo endpoint de /v1/plan/ que modifica datos acepta agent_name en un cuerpo JSON, o el header X-Dailybot-Agent-Name (UTF-8 codificado con percent-encoding) en escrituras multipart y sin cuerpo. Gana el cuerpo; el máximo es de 128 caracteres, y un nombre más largo o imposible de decodificar es 400 invalid_agent_attribution. Una key de tipo agente que lo envía recibe el mismo error. El sello nunca cambia una respuesta de permisos.
• Respuestas — los comentarios, adjuntos y elementos de actividad llevan executed_by_agent ({uuid, name, username, avatar} o null); una tarea gana executors (del más reciente al más antiguo, con first_at y last_at), distinto del executor singular.
• Keys — una API key personal actúa como su persona (consulta la entrada de arriba). Los objetos privados siguen siendo 404 para quien no fue invitado. Ver Atribución de agente.

2026-09-26 · Cambiado — Permisos open-org de Plan (Plan Beta)

• Todo miembro no invitado tiene tasks:read, tasks:write y tasks:admin. Los miembros pueden crear objetivos, proyectos y tableros (y gestionar estados y membresías). tasks:admin significa escrituras de contenedores — ya no es solo admin de la org. Los invitados siguen rechazados con 403 guest_not_allowed antes del entitlement.
• La invitación es la palanca de acceso. La privacidad es la membresía, no el rol de la organización. Los contenedores de toda la organización son un espacio compartido. Un proyecto o tablero members es 404 (no visible) sin grant. Invita a una persona o a un equipo; el último grant en un contenedor privado es 409 last_grant_cannot_be_removed. No hay roles por proyecto (lead/viewer).
• Supervisión: los administradores de la organización y los managers de todos los equipos pueden ver todos los proyectos; un tablero members sigue necesitando un grant.
• Las API keys de la organización siguen sin tener tasks:admin — no pueden cambiar quién ve (membresía) ni a quién se notifica (participantes) (403 insufficient_scope).
• PATCH /v1/plan/projects/{project_id}/ persiste visibility y otorga automáticamente al actor que privatiza (org → members). Consulta Autenticación para Plan.

2026-09-25 · Agregado — Adjuntos en comentarios, objetivos y proyectos (Plan Beta)

• Adjuntos de comentarios — GET/POST /v1/plan/tasks/{task_id}/comments/{comment_id}/attachments/, GET …/{attachment_id}/content/ y DELETE …/{attachment_id}/. Solo el autor del comentario adjunta; quien lo subió, el autor del comentario o un administrador de la organización pueden quitarlo. Las filas de comentarios ahora traen attachments, sus adjuntos listos por posición.
• Adjuntos de proyectos y objetivos — las mismas cuatro operaciones bajo /v1/plan/projects/{project_id}/attachments/ y /v1/plan/goals/{goal_id}/attachments/. Cualquiera que pueda ver el proyecto o el objetivo puede listar y descargar; subir y quitar requieren un miembro no invitado con sesión iniciada y tasks:admin (todo miembro no invitado lo tiene; una API key recibe 403 insufficient_scope).
• Reglas de carga — solo multipart/form-data (file, caption opcional), hasta 5 MiB (400 attachment_too_large con extra.max_size_bytes), los mismos tipos de archivo que los adjuntos de tareas y como máximo 50 por comentario, proyecto u objetivo. Las descargas transmiten los bytes con nosniff y no-store. Refiérete a una imagen en una descripción como attachment:{uuid} y resuélvela con el url firmado de la lista, que vence a los 15 minutos.
• Actividad — task.comment_attached, task.comment_detached, goal.attached, goal.detached, project.attached y project.detached aparecen en la actividad; no son eventos de webhook.

2026-09-25 · Seguridad + Agregado + Cambiado — API de Dailybot Plan (Beta)

• Seguridad: las keys se rechazan en toda operación tasks:admin — crear, editar, archivar y restaurar proyectos, tableros, estados del flujo de trabajo y objetivos, reordenar estados, gestionar los miembros de tableros y proyectos, y vincular objetivos a proyectos requieren un miembro no invitado con sesión iniciada (tasks:admin; todo miembro no invitado lo tiene tras el login). Una API key de la organización recibe 403 insufficient_scope. Consulta los endpoints solo para personas. En parte supersedido por el cambio open-org del 2026-09-26 arriba (miembros, no solo admins de la org).
• Seguridad: el selector de menciones ya no devuelve direcciones de correo — las filas de GET /v1/plan/boards/{board_id}/mentionables/ son {uuid, name, handle, avatar_url, has_photo, kind}, sin correo, y q coincide con un nombre, un handle o un id externo, nunca con una dirección de correo completa.
• Agregado: la creación en lote puede ir arriba — POST /v1/plan/tasks/bulk/ con operation: create acepta un position opcional: start pone las tareas nuevas arriba de cada columna, en el orden de los elementos; end (el valor por defecto) las deja al final.
• Agregado: el selector de menciones incluye avatares — cada fila ahora tiene avatar_url (texto o null) y has_photo, con el mismo significado que en el responsable de una tarea: cuando has_photo es false, muestra las iniciales. En una fila agent son null y false.
• Cambiado: las operaciones con simulación documentan su vista previa — archivar un proyecto, tablero, estado del flujo de trabajo, tarea u objetivo, y completar un hito, responden un DryRunPreview con ?dry_run=true: {operation, dry_run, reversible, restore_path, consequence, affects}, más would_refuse y refusal_code al archivar un estado del flujo de trabajo. El lote mantiene su propia vista previa.
• Cambiado: la simulación en lote reporta todos los cambios — POST /v1/plan/tasks/bulk/?dry_run=true ahora incluye en changes los cambios de labels, rank, estimate y start_date.

2026-09-25 · Agregado — API de Dailybot Plan (Beta)

• API de Plan, en beta — 117 operaciones bajo /v1/plan/ para proyectos, objetivos, tableros, estados, tareas, comentarios, adjuntos, favoritos, vistas guardadas, actividad, bandeja de entrada, línea de tiempo y búsqueda. Todo lo que está bajo /v1/plan/ está marcado como Beta y puede cambiar antes de la disponibilidad general. Hasta que tu organización esté habilitada, los endpoints de Plan responden 402 plan_upgrade_required; escribe a [email protected] para unirte.
• Inicio en una sola solicitud — GET /v1/plan/pulse/ acepta include=projects,attention,activity,goal_progress, y la respuesta indica su población con scope: "viewer_visible".
• Actualizaciones de proyectos en lote — GET /v1/plan/projects/updates/ devuelve las actualizaciones más recientes de todos los proyectos que puedes ver.
• Mis tareas — GET /v1/plan/me/tasks/counts/ agrega by_scope con {total, open, overdue, blocked}, y el filtro state de GET /v1/plan/me/tasks/ acepta uuids de estado o open / done.
• Simulación en lote — POST /v1/plan/tasks/bulk/?dry_run=true ejecuta la llamada y la revierte.
• Lecturas más rápidas — Las lecturas de Plan son más rápidas, con las mismas respuestas.
• Feed de cambios — since en GET /v1/plan/boards/{board_id}/delta/ es un alias obsoleto de updated_since; envía updated_since. No se anunció una fecha de retiro.

Documentado en /es/developers/plan y en los seis grupos de Plan de la referencia de la API.

2026-08-25 · Añadido — CLI Etiquetas/Featured, DMs a equipos aprobadores y aprobaciones programáticas

• CLI y Agent Skill — dailybot label … y dailybot featured … envuelven Etiquetas y Featured (dailybot-cli >= 3.9.0). Sub-skills dailybot-labels y dailybot-featured.
• Aprobación — fan-out por equipo — Si un formulario lista un equipo como aprobador, cada miembro activo recibe el mensaje Aprobar/Rechazar en el chat (DM de Slack).
• Aprobación — API / CLI — POST /v1/forms/{uuid}/responses/{uuid}/approval/ con action_status y comment opcional. CLI: dailybot form response approve|deny.
• Web app — Aprobadores de equipo pueden actuar en el modal cuando la API expone user_can_approve.

Documentado en /es/developers/cli, /es/developers/agent-skill y /es/developers/api/forms.

2026-08-03 · Añadido — Etiquetas organizacionales, personalización y comentarios de aprobación

• Etiquetas organizacionales — CRUD público en /v1/labels/ más asignación POST en formularios, automatizaciones y check-ins. Elegible cuando la función está habilitada y el llamante no es invitado; invitados denegados. Filtros labels= (al menos una de las etiquetas seleccionadas / OR), featured=, prioritize_featured=true. labels: LabelSummary[] e is_featured (privado) en filas de listado (y en detalle de Formularios).
• Personalización (/v1/me/...) — Preferencias de dashboard, vistas guardadas y Featured. No requiere elegibilidad de Etiquetas.
• Comentarios de flujo de aprobación — approval_flow_comments_enabled (solo lectura en payloads). Comentario opcional breve en web (si excede el límite se rechaza); modal en Slack. Microsoft Teams, Discord y Google Chat no recogen comentarios de aprobación desde el chat hoy — usa la web. Configurar en la UI Setup — no vía PATCH .../config/.
• Enriquecimiento de listados — cuando no está disponible, params de enriquecimiento → 503 dashboard_enrichment_temporarily_unavailable. Códigos en /es/developers/errors.

Documentado en /es/developers/api/labels, /es/developers/api/users, /es/developers/api/forms, /es/developers/api/check-ins y /es/developers/api/workflows.

2026-07-23 · Añadido — Contrato de botones interactivos v3.1: Modal → Workflow + {{trigger.*}}

modal_body ahora se compone con callback_workflow (además de callback_url). Al enviar, los valores de los campos del modal se entregan al workflow api_trigger disparado como {{trigger.fields.<name>}}. Los pasos del workflow ganan el namespace canónico {{trigger.*}} (source, body.*, button_id, button_value, fields.*, clicked_at, user.*, triggered_by_user_uuid) para ramificación por valor de botones y prellenado de formularios modal-a-workflow. Las credenciales callback_auth de botones / request_auth de workflows son solo escritura (las lecturas devuelven una máscara ***).

Documentado en /es/developers/api/messaging y /es/developers/api/workflows.

2026-07-23 · Añadido — Workflows api_trigger + POST /v1/workflows/{uuid}/trigger/

Nuevo tipo de trigger de workflow disparado solo desde fuera del motor: el endpoint público de trigger (202 Accepted, ejecución async, payload JSON opcional ≤8 KiB) o el callback_workflow de un botón interactivo (resuelve exclusivamente a workflows activos api_trigger). Seleccionable en el constructor de automatizaciones como When triggered via API or button. Los errores incluyen workflow_not_triggerable, workflow_trigger_payload_invalid, workflow_execute_not_allowed y workflow_frozen.

Documentado en /es/developers/api/workflows.

2026-07-23 · Añadido — request_auth en la acción de workflow Send-a-Request

El paso de automatización SEND_REQUEST acepta autenticación estática opcional con la misma forma que callback_auth de botones interactivos — bearer, basic o custom_header (token RFC 7230; nombres de header reservados denegados). Los valores admiten {{variables}}; las credenciales nunca aparecen en las salidas del paso.

Documentado en /es/developers/api/workflows (patrones de trigger + auth) y /es/developers/api/messaging (callback_auth).

2026-07-23 · Añadido — Contrato de botones interactivos v3: callback_prompt, callback_workflow, response, callback_auth

Cuatro adiciones al envelope de botones de /v1/send-message/: (1) callback_command es un slot de comando conocido (≤200 chars); los prompts de IA en texto libre pasan a callback_prompt (≤2000, se ejecuta como el clicador) — el prefijo "prompt: …" se rechaza con 400 button_callback_command_invalid; (2) callback_workflow (UUID de workflow) dispara un workflow interno; (3) response adjunta una auto-respuesta a cualquier botón (ack instantáneo en paralelo con callback_url, botones anidados recursivos con límites de profundidad/tamaño); (4) callback_auth añade auth de transporte estática opcional a los POST de callback — aditivo a la firma HMAC siempre activa. La exclusividad mutua abarca los cinco callbacks.

Documentado en /es/developers/api/messaging.

2026-07-23 · Añadido — Botones interactivos: callback_url, modal_body, callback_form, callback_command (778e5d6cd)

Un botón interactive puede disparar POST salientes firmados a callback_url (HMAC-SHA256, estilo Stripe X-Dailybot-Signature: t=…, v1=…, ventana de replay de 5 minutos, clave de idempotencia X-Dailybot-Delivery), abrir un modal de plataforma desde modal_body, abrir un formulario interno de Dailybot vía callback_form, o ejecutar un comando conocido vía callback_command. Cada botón interactivo lleva un id generado por el servidor $btn/<uuid>. Google Chat se entrega como plataforma hangouts. Aditivo — las rutas legacy payload.callback_config / action siguen funcionando.

Documentado en /es/developers/api/messaging.

2026-07-13 · Agregado + Cambiado + Deprecado — Lista de formularios: filtro por propietario, visibilidad organizacional y deprecaciones

• Filtra la lista de formularios por propietario: pasa owner_user_ids=<uuid>,<uuid> a GET /v1/forms/ para ver solo sus formularios, y usa el nuevo endpoint GET /v1/forms/form-owners/ para descubrir qué miembros poseen formularios (buscable y paginado). Los emails de miembros están ocultos en los payloads del selector a menos que el llamante sea admin o manager.
• No más formularios “faltantes”: todos los formularios de tu organización ahora aparecen en la lista y búsqueda (GET /v1/forms/), así un formulario ya no puede ser accesible por UUID pero ausente de la lista. Los permisos del formulario (editar, ver respuestas, cambiar estados) no se ven afectados.
• Deprecado: filter=me en la lista de formularios — usa owner_user_ids con tu propio UUID. available_on_list_view también está obsoleto e ignorado del lado del servidor. Ambos campos se aceptan indefinidamente; la remoción se anunciará como una entrada de changelog separada con su propia ventana de migración.

Documentado en /developers/api/forms.

2026-07-12 · Agregado — Forms API v2: filtrado avanzado y automación

Lista de formularios (GET /v1/forms/): Agregados filter (all/me/public/approval/workflow/archived), order (alphabetical/recent/total), is_ascend, search, include=questions, include_archived y parámetros de rango de fechas. Nuevos campos de respuesta: workflow_enabled, approval_flow_enabled, created_at.

Lista de respuestas (GET /v1/forms/{uuid}/responses/): Agregados submission_sources (multi-selección: member/anonymous/automation/public), submitter_user_ids (multi-selección de UUIDs), flow_status (pending/approved/denied), order (recent/oldest) e is_ascend. Nuevos campos de respuesta: is_anonymous, flow_status, content, submission_source, guest_user. La búsqueda ahora incluye nombre/email del autor.

Enviar respuesta (POST /v1/forms/{uuid}/responses/): Agregado modo automation (sin atribución de autor), modo anonymous (nombre aleatorio), guest_user (identidad de invitado para automación) y submission_source (etiqueta de procedencia). Nuevos campos de respuesta: is_guest_user, guest_user, submission_source.

Todos los nuevos parámetros son opcionales — omitirlos produce el mismo comportamiento anterior. Sin cambios rompedores. Documentado en /es/developers/api/forms.

2026-07-10 · Cambiado — Filtro de kudos sin distinción de mayúsculas

?filter= en GET /v1/kudos/ y GET /v1/kudos/organization/ ahora acepta cualquier capitalización (kudos_received, KUDOS_RECEIVED, Kudos_Received). Los valores inválidos devuelven 400 con code: "invalid_kudos_filter" (reemplaza not_valid_kudos_filter). Documentado en /es/developers/api/kudos.

2026-07-10 · Añadido — Filtro de estado de workflow en respuestas de formulario

GET /v1/forms/{uuid}/responses/?state=<state> filtra respuestas por estado de workflow en formularios con workflow habilitado. Los estados inválidos devuelven 400 con code: "invalid_workflow_state". Documentado en /es/developers/api/forms.

2026-07-10 · Añadido — Búsqueda en /v1/kudos/organization/

GET /v1/kudos/organization/ ahora admite ?search= (subcadena sin distinción de mayúsculas en el contenido del kudo, máx. 256 chars). Documentado en /es/developers/api/kudos.

2026-07-10 · Cambiado — Endpoints de agentes devuelven id y uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/ y pending_messages en GET /v1/agent-health/ ahora devuelven id y uuid con el mismo valor UUID por retrocompatibilidad. Prefiere uuid en integraciones nuevas. Documentado en /es/developers/api/agents.

2026-07-10 · Rompedor — Paginación siempre activa en todos los endpoints de lista

Se eliminó el mecanismo de opt-in para paginación en GET /v1/forms/ y GET /v1/forms/{uuid}/responses/. Cada endpoint de lista ahora devuelve el envelope estándar { count, next, previous, results } por defecto. Acción requerida: si dependías de la respuesta como array simple, envuelve tu consumidor en el envelope (response.results). El query parameter ?paginated=true y el header X-Dailybot-Paginate dejaron de tener efecto. Documentado en /es/developers/conventions#pagination.

2026-07-10 · Rompedor — Endpoints de formularios devuelven uuid en lugar de id

Todos los endpoints /v1/forms/** ahora devuelven el identificador del recurso bajo la clave uuid en lugar de id. Esto alinea forms con la convención de identificadores de Dailybot — los recursos con columna UUID dedicada exponen uuid; solo los recursos cuya clave primaria ES un UUID exponen id. Acción requerida: reemplaza response.id / data["id"] por response.uuid / data["uuid"] en toda integración de forms. Las rutas de URL (/v1/forms/{uuid}/) no cambian. Documentado en /es/developers/api/forms.

2026-07-10 · Cambiado — Endpoints de agentes devuelven uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/ y el arreglo pending_messages en GET /v1/agent-health/ ahora devuelven el identificador del recurso bajo la clave uuid. Documentado en /es/developers/api/agents.

2026-07-10 · Añadido — Filtros en /v1/kudos/ y /v1/workflows/

Ambos endpoints ahora admiten ?start_date, ?end_date (YYYY-MM-DD, zona horaria del llamante) y ?search (subcadena sin distinción de mayúsculas en el contenido de mensaje para kudos, en nombre de workflow para workflows; máx. 256 chars). Estos filtros antes se aceptaban pero se ignoraban silenciosamente — ahora son totalmente funcionales. Documentado en /es/developers/api/kudos y /es/developers/api/workflows.

2026-07-10 · Cambiado — /v1/kudos/organization/ acepta tokens CLI Bearer

GET /v1/kudos/organization/ requería antes una API key de organización (X-API-KEY únicamente). Ahora también acepta tokens CLI Bearer (Authorization: Bearer <token>). El requisito de rol admin de la organización no cambia. Documentado en /es/developers/api/kudos.

2026-07-10 · Añadido — Nuevos códigos de error de validación

Seis nuevos códigos legibles por máquina, documentados y aplicados de forma uniforme:

• invalid_user_identifier (HTTP 400) — ?user= no es un UUID válido (aplica a /v1/checkins/{uuid}/responses/ y /v1/forms/{uuid}/responses/).
• invalid_date_range (HTTP 400) — la fecha no es YYYY-MM-DD, o start_date > end_date.
• search_query_too_long (HTTP 400) — ?search= excede 256 caracteres.
• invalid_kudos_filter (HTTP 400) — ?filter= en /v1/kudos/ o /v1/kudos/organization/ no es uno de kudos_received / kudos_given.
• invalid_workflow_state (HTTP 400) — ?state= en /v1/forms/{uuid}/responses/ no es válido para el workflow del form.
• form_response_view_all_forbidden (HTTP 403) — un miembro usó ?all=true en un form restringido.
• invalid_sender_uuid / invalid_receiver_uuid (HTTP 400) — ?sender_uuid= o ?receiver_uuid= en /v1/kudos/organization/ no es un UUID válido.

Toda respuesta de error /v1/** está garantizada como application/json — sin páginas HTML de error para validación de entrada del cliente. Documentado en /es/developers/errors#machine-codes.

2026-07-10 · Añadido — Filtros, schema de respuesta y contrato de errores de /v1/kudos/organization/

Se documentó por completo el endpoint GET /v1/kudos/organization/: solo admin, siempre paginado, ordenado por created_at DESC (con id como criterio de desempate), solo kudos de nivel superior. Filtros: filter (kudos_received / kudos_given), start_date / end_date con zona horaria, date_start / date_end legacy por día (ambas parejas se acumulan), y sender_uuid / receiver_uuid. Los campos de respuesta (user, receivers, company_value, content, is_anonymous, created_at) y los cuatro códigos de validación 400 (invalid_date_range, invalid_kudos_filter, invalid_sender_uuid, invalid_receiver_uuid) están ahora en la página del endpoint. Documentado en /es/developers/api/kudos#get-v1kudosorganization.

2026-07-09 · Añadido — Paginación unificada en todos los endpoints de lista

Todos los endpoints de lista /v1/ ahora devuelven el envelope estándar { count, next, previous, results } de forma uniforme. Se añadieron parámetros canónicos page / page_size. Los aliases heredados limit / offset siguen aceptándose. Documentado en /es/developers/conventions#pagination.

2026-07-09 · Añadido — Parámetro de búsqueda en endpoints de lista

Se añadió ?search=<término> (subcadena sin distinción de mayúsculas, máx. 256 chars) en forms, check-ins, respuestas de forms, respuestas de check-ins y usuarios. Documentado en /es/developers/conventions#search.

2026-07-09 · Añadido — Parámetros canónicos de rango de fechas

Parámetros unificados ?start_date / ?end_date (YYYY-MM-DD, zona horaria del llamante) en todos los endpoints paginados. Los aliases heredados date_start/date_end y date_from/date_to siguen funcionando. Documentado en /es/developers/conventions#date-range.

2026-07-09 · Añadido — Códigos de error legibles por máquina en todas las respuestas de error

Cada respuesta non-2xx ahora lleva un campo code estable junto a detail. Despacha sobre code, nunca parsees la prosa. Referencia completa en /es/developers/errors#machine-codes.

2026-07-09 · Añadido — Throttles diarios de plan gratuito en agent-reports y send-email

POST /v1/agent-reports/ limitado a 50 por org por día en planes gratuitos. POST /v1/send-email/ limitado a 20 por org por día. Documentado en /es/developers/rate-limits#free-plan-throttles.

2026-07-09 · Añadido — Sustitución de identidad send_as_user en POST /v1/send-message/

Nuevo campo send_as_user (UUID) en POST /v1/send-message/ — solo Slack, requiere admin. Documentado en /es/developers/api/messaging#send-as-user.

2026-07-09 · Añadido — Ciclo de vida show-once y acceso de miembros a API keys

Los secretos de API key ahora son show-once: solo se devuelven al crear o regenerar. Los miembros (no admin) ahora pueden crear y gestionar sus propias API keys. Documentado en /es/developers/authentication#api-key-secret-lifecycle-show-once.

2026-07-09 · Añadido — Allowlist de plan gratuito para tokens CLI Bearer

Documentación explícita del allowlist de endpoints para tokens CLI Bearer en planes gratuitos. Documentado en /es/developers/authentication#cli-bearer-tokens-free-plan-allowlist.

2026-07-09 · Cambiado — Las API keys funcionan en TODOS los endpoints /v1/

Confirmado y documentado: las API keys no están restringidas a operaciones de agentes — funcionan en todos los endpoints públicos /v1/. Nueva matriz de métodos de autenticación en /es/developers/authentication#parity-matrix.

2026-07-09 · Removido — Opt-in de paginación con array simple en endpoints de forms

Se eliminó el default deprecado de array simple en GET /v1/forms/ y GET /v1/forms/{uuid}/responses/. La paginación ahora es siempre activa — ver la entrada rompedora del 2026-07-10 arriba.

2026-07-09 · Deprecado — Endpoints /v1/followups/

GET /v1/followups/ y GET /v1/followups/{uuid}/responses/ están deprecados. Usa GET /v1/checkins/ y GET /v1/checkins/{uuid}/responses/.

2026-07-07 · Cambiado — Respuestas de check-in: listado por defecto restaurado + filtro user

• El endpoint GET /v1/checkins/{uuid}/responses/ ahora devuelve correctamente las respuestas de todos los participantes por defecto (se corrigió una regresión de un release anterior).
• Se añadió el parámetro opcional ?user=<uuid> para que propietarios de API key admin/manager filtren respuestas a un participante específico.
• El parámetro ?all=true no aplica a respuestas de check-in y no debe documentarse para este endpoint.

2026-07-06 · Añadido — API de authoring para formularios y check-ins

Authoring programático completo: crear, configurar, archivar y gestionar preguntas. Nuevo endpoint GET /v1/report-channels/. Requiere rol admin/manager y CLI:write. Documentado en /es/developers/api/forms y /es/developers/api/check-ins.

2026-07-06 · Cambiado — Validación estricta de config y filtros de respuestas de formulario

Los endpoints de config rechazan campos desconocidos con 400 unknown_field. Listados con include_archived. El listado de respuestas de formulario (no de check-in) admite all, user, date_from, date_to. Admins pueden editar respuestas ajenas.

2026-07-02 · Añadido — Referencia trilingüe de la API en /developers/api/

Cada uno de los 101 endpoints de la API pública en 18 grupos ahora tiene una página de referencia dedicada renderizada desde una colección de contenido. Cada endpoint documenta métodos de auth, parámetros, schemas de request/response, códigos de error y scope de rate-limit. Espejos trilingües en /es/ y /pt/.

2026-07-02 · Compromiso — Compromiso de paridad: API key vs. CLI Bearer

Formalizamos el compromiso de diseño de que todo endpoint no CLI-only acepta ambos tipos de credencial con forma de respuesta idéntica. Ver /es/developers/authentication#parity-guarantee. El rollout de la aplicación en api-services está en curso y se logueará aquí al completar.