Skip to content

Changelog de la API · Developers

El log en vivo de adiciones y cambios de comportamiento confirmados en la API pública de Dailybot.

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-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/agent-reports.

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/agent-reports.

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.