Changelog da API · Developers

Mudanças aditivas na API pública do Dailybot chegam continuamente. Mudanças breaking chegam em um novo prefixo de URL (/v2/) com um sunset mínimo de seis meses sobre a versão anterior. Esta página é o log ao vivo — adicione ao seu leitor e você nunca terá que adivinhar quando um novo endpoint apareceu.

O que qualifica como mudança

Logamos quatro categorias: Adicionado (endpoint novo, campo novo em resposta, query param novo), Alterado (comportamento de endpoint existente mudou de forma compatível), Depreciado (feature que planejamos remover, sempre com a data mais próxima de remoção), e Removido (remoção breaking, sempre anunciada ≥ 6 meses antes como Depreciado). Não logamos mudanças puramente internas.

Entradas

2026-07-13 · Adicionado + Alterado + Depreciado — Lista de formulários: filtro por proprietário, visibilidade organizacional e depreciações

• Filtre a lista de formulários por proprietário: passe owner_user_ids=<uuid>,<uuid> para GET /v1/forms/ para ver apenas seus formulários, e use o novo endpoint GET /v1/forms/form-owners/ para descobrir quais membros possuem formulários (pesquisável e paginado). Os emails dos membros estão ocultos nos payloads do seletor a menos que o chamador seja admin ou manager.
• Sem mais formulários “faltando”: todos os formulários da sua organização agora aparecem na lista e busca (GET /v1/forms/), então um formulário não pode mais ser acessível por UUID mas ausente da lista. As permissões do formulário (editar, ver respostas, mudar estados) não são afetadas.
• Depreciado: filter=me na lista de formulários — use owner_user_ids com seu próprio UUID. available_on_list_view também está obsoleto e ignorado no servidor. Ambos os campos continuam sendo aceitos indefinidamente; a remoção será anunciada como uma entrada de changelog separada com sua própria janela de migração.

Documentado em /developers/api/forms.

2026-07-12 · Adicionado — Forms API v2: filtragem avançada e automação

Lista de formulários (GET /v1/forms/): Adicionados filter (all/me/public/approval/workflow/archived), order (alphabetical/recent/total), is_ascend, search, include=questions, include_archived e parâmetros de intervalo de datas. Novos campos de resposta: workflow_enabled, approval_flow_enabled, created_at.

Lista de respostas (GET /v1/forms/{uuid}/responses/): Adicionados submission_sources (multi-seleção: member/anonymous/automation/public), submitter_user_ids (multi-seleção de UUIDs), flow_status (pending/approved/denied), order (recent/oldest) e is_ascend. Novos campos de resposta: is_anonymous, flow_status, content, submission_source, guest_user. A busca agora inclui nome/email do autor.

Enviar resposta (POST /v1/forms/{uuid}/responses/): Adicionado modo automation (sem atribuição de autor), modo anonymous (nome aleatório), guest_user (identidade de convidado para automação) e submission_source (rótulo de procedência). Novos campos de resposta: is_guest_user, guest_user, submission_source.

Todos os novos parâmetros são opcionais — omiti-los produz o mesmo comportamento anterior. Sem mudanças breaking. Documentado em /pt/developers/api/forms.

2026-07-10 · Alterado — Filtro de kudos sem distinção de maiúsculas

?filter= em GET /v1/kudos/ e GET /v1/kudos/organization/ agora aceita qualquer capitalização (kudos_received, KUDOS_RECEIVED, Kudos_Received). Valores inválidos retornam 400 com code: "invalid_kudos_filter" (substitui not_valid_kudos_filter). Documentado em /pt/developers/api/kudos.

2026-07-10 · Adicionado — Filtro de estado de workflow em respostas de formulário

GET /v1/forms/{uuid}/responses/?state=<state> filtra respostas por estado de workflow em formulários com workflow habilitado. Estados inválidos retornam 400 com code: "invalid_workflow_state". Documentado em /pt/developers/api/forms.

2026-07-10 · Adicionado — Busca em /v1/kudos/organization/

GET /v1/kudos/organization/ agora suporta ?search= (substring sem distinção de maiúsculas no conteúdo do kudo, máx. 256 chars). Documentado em /pt/developers/api/kudos.

2026-07-10 · Alterado — Endpoints de agentes retornam id e uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/ e pending_messages em GET /v1/agent-health/ agora retornam id e uuid com o mesmo valor UUID por retrocompatibilidade. Prefira uuid em novas integrações. Documentado em /pt/developers/api/agent-reports.

2026-07-10 · Breaking — Paginação sempre ativa em todos os endpoints de lista

O mecanismo de opt-in para paginação em GET /v1/forms/ e GET /v1/forms/{uuid}/responses/ foi removido. Todo endpoint de lista agora retorna o envelope padrão { count, next, previous, results } por padrão. Ação necessária: se você dependia da resposta como array simples, envolva seu consumidor no envelope (response.results). O query parameter ?paginated=true e o header X-Dailybot-Paginate deixaram de ter efeito. Documentado em /pt/developers/conventions#pagination.

2026-07-10 · Breaking — Endpoints de formulários retornam uuid em vez de id

Todos os endpoints /v1/forms/** agora retornam o identificador do recurso sob a chave uuid em vez de id. Isso alinha forms com a convenção de identificadores do Dailybot — recursos com coluna UUID dedicada expõem uuid; apenas recursos cuja chave primária É um UUID expõem id. Ação necessária: substitua response.id / data["id"] por response.uuid / data["uuid"] em toda integração de forms. As rotas de URL (/v1/forms/{uuid}/) não mudam. Documentado em /pt/developers/api/forms.

2026-07-10 · Alterado — Endpoints de agentes retornam uuid

POST /v1/agent-reports/, GET /v1/agent-messages/, POST /v1/agent-messages/ e o array pending_messages em GET /v1/agent-health/ agora retornam o identificador do recurso sob a chave uuid. Documentado em /pt/developers/api/agent-reports.

2026-07-10 · Adicionado — Filtros em /v1/kudos/ e /v1/workflows/

Ambos os endpoints agora suportam ?start_date, ?end_date (YYYY-MM-DD, fuso horário do chamador) e ?search (substring sem distinção de maiúsculas no conteúdo da mensagem para kudos, no nome do workflow para workflows; máx. 256 chars). Esses filtros antes eram aceitos mas silenciosamente ignorados — agora são totalmente funcionais. Documentado em /pt/developers/api/kudos e /pt/developers/api/workflows.

2026-07-10 · Alterado — /v1/kudos/organization/ aceita tokens CLI Bearer

GET /v1/kudos/organization/ exigia antes uma chave de API da organização (X-API-KEY apenas). Agora também aceita tokens CLI Bearer (Authorization: Bearer <token>). O requisito de função de admin da organização permanece. Documentado em /pt/developers/api/kudos.

2026-07-10 · Adicionado — Novos códigos de erro de validação

Seis novos códigos legíveis por máquina, documentados e aplicados de forma uniforme:

• invalid_user_identifier (HTTP 400) — ?user= não é um UUID válido (aplica-se a /v1/checkins/{uuid}/responses/ e /v1/forms/{uuid}/responses/).
• invalid_date_range (HTTP 400) — a data não é YYYY-MM-DD, ou start_date > end_date.
• search_query_too_long (HTTP 400) — ?search= excede 256 caracteres.
• invalid_kudos_filter (HTTP 400) — ?filter= em /v1/kudos/ ou /v1/kudos/organization/ não é um de kudos_received / kudos_given.
• invalid_workflow_state (HTTP 400) — ?state= em /v1/forms/{uuid}/responses/ não é válido para o workflow do form.
• form_response_view_all_forbidden (HTTP 403) — um membro usou ?all=true em um form restrito.
• invalid_sender_uuid / invalid_receiver_uuid (HTTP 400) — ?sender_uuid= ou ?receiver_uuid= em /v1/kudos/organization/ não é um UUID válido.

Toda resposta de erro /v1/** é garantida como application/json — sem páginas HTML de erro para validação de entrada do cliente. Documentado em /pt/developers/errors#machine-codes.

2026-07-10 · Adicionado — Filtros, schema de resposta e contrato de erros de /v1/kudos/organization/

O endpoint GET /v1/kudos/organization/ foi totalmente documentado: apenas admin, sempre paginado, ordenado por created_at DESC (com id como critério de desempate), apenas kudos de nível superior. Filtros: filter (kudos_received / kudos_given), start_date / end_date com fuso horário, date_start / date_end legado por dia (ambos os pares se combinam), e sender_uuid / receiver_uuid. Os campos da resposta (user, receivers, company_value, content, is_anonymous, created_at) e os quatro códigos de validação 400 (invalid_date_range, invalid_kudos_filter, invalid_sender_uuid, invalid_receiver_uuid) estão agora na página do endpoint. Documentado em /pt/developers/api/kudos#get-v1kudosorganization.

2026-07-09 · Adicionado — Paginação unificada em todos os endpoints de lista

Todos os endpoints de lista /v1/ agora retornam o envelope padrão { count, next, previous, results } de forma uniforme. Parâmetros canônicos page / page_size adicionados. Aliases legados limit / offset continuam aceitos. Documentado em /pt/developers/conventions#pagination.

2026-07-09 · Adicionado — Parâmetro de busca em endpoints de lista

Adicionado ?search=<termo> (substring sem distinção de maiúsculas, máx. 256 chars) em forms, check-ins, respostas de forms, respostas de check-ins e usuários. Documentado em /pt/developers/conventions#search.

2026-07-09 · Adicionado — Parâmetros canônicos de intervalo de datas

Parâmetros unificados ?start_date / ?end_date (YYYY-MM-DD, fuso horário do chamador) em todos os endpoints paginados. Aliases legados continuam funcionando. Documentado em /pt/developers/conventions#date-range.

2026-07-09 · Adicionado — Códigos de erro legíveis por máquina em todas as respostas de erro

Cada resposta non-2xx agora carrega um campo code estável junto a detail. Despache sobre code, nunca faça parse da prosa. Referência completa em /pt/developers/errors#machine-codes.

2026-07-09 · Adicionado — Throttles diários do plano gratuito em agent-reports e send-email

POST /v1/agent-reports/ limitado a 50 por org por dia em planos gratuitos. POST /v1/send-email/ limitado a 20 por org por dia. Documentado em /pt/developers/rate-limits#free-plan-throttles.

2026-07-09 · Adicionado — Substituição de identidade send_as_user em POST /v1/send-message/

Novo campo send_as_user (UUID) em POST /v1/send-message/ — só Slack, requer admin. Documentado em /pt/developers/api/messaging#send-as-user.

2026-07-09 · Adicionado — Ciclo de vida show-once e acesso de membros a API keys

Segredos de API key agora são show-once: só retornados na criação ou regeneração. Membros (não-admin) agora podem criar e gerenciar suas próprias API keys. Documentado em /pt/developers/authentication#api-key-secret-lifecycle-show-once.

2026-07-09 · Adicionado — Allowlist de plano gratuito para tokens CLI Bearer

Documentação explícita do allowlist de endpoints para tokens CLI Bearer em planos gratuitos. Documentado em /pt/developers/authentication#cli-bearer-tokens-free-plan-allowlist.

2026-07-09 · Alterado — API keys funcionam em TODOS os endpoints /v1/

Confirmado e documentado: API keys não são restritas a operações de agentes — funcionam em todos os endpoints públicos /v1/. Nova matriz de métodos de autenticação em /pt/developers/authentication#parity-matrix.

2026-07-09 · Removido — Opt-in de paginação com array simples em endpoints de forms

O default depreciado de array simples em GET /v1/forms/ e GET /v1/forms/{uuid}/responses/ foi removido. A paginação agora é sempre ativa — veja a entrada breaking de 2026-07-10 acima.

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

GET /v1/followups/ e GET /v1/followups/{uuid}/responses/ estão depreciados. Use GET /v1/checkins/ e GET /v1/checkins/{uuid}/responses/.

2026-07-07 · Alterado — Respostas de check-in: listagem padrão restaurada + filtro user

• O endpoint GET /v1/checkins/{uuid}/responses/ agora retorna corretamente as respostas de todos os participantes por padrão (regressão de um release anterior foi corrigida).
• Adicionado parâmetro opcional ?user=<uuid> para proprietários de chave de API admin/manager filtrarem respostas de um participante específico.
• O parâmetro ?all=true não se aplica a respostas de check-in e não deve ser documentado para este endpoint.

2026-07-06 · Adicionado — API de authoring para formulários e check-ins

Authoring programático completo: criar, configurar, arquivar e gerenciar perguntas. Novo endpoint GET /v1/report-channels/. Requer função admin/manager e CLI:write. Documentado em /pt/developers/api/forms e /pt/developers/api/check-ins.

2026-07-06 · Alterado — Validação estrita de config e filtros de respostas de formulário

Endpoints de config rejeitam campos desconhecidos com 400 unknown_field. Listagens com include_archived. Listagem de respostas de formulário (não de check-in) com all, user, date_from, date_to. Admins podem editar respostas de terceiros.

2026-07-02 · Adicionado — Referência trilíngue da API em /developers/api/

Cada um dos 101 endpoints da API pública em 18 grupos agora tem uma página de referência dedicada renderizada de uma coleção de conteúdo. Cada endpoint documenta métodos de auth, parâmetros, schemas de request/response, códigos de erro e escopo de rate-limit. Espelhos trilíngues em /es/ e /pt/.

2026-07-02 · Compromisso — Compromisso de paridade: chave de API vs. CLI Bearer

Formalizamos o compromisso de projeto de que todo endpoint não-CLI-only aceita ambos os tipos de credencial com forma de resposta idêntica. Veja /pt/developers/authentication#parity-guarantee. O rollout da aplicação em api-services está em curso e será logado aqui ao completar.