Changelog da API

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-09-30 · Adicionado — Notificações, resumo pessoal e relatórios agendados (Plan Beta)

• Catálogo de notificações e chaves pessoais — GET /v1/plan/notifications/catalog/ lista todos os tipos; GET / PUT /v1/plan/me/notifications/ leem e alteram as suas chaves por tipo e canal (DM e/ou e-mail), e para onde vão os DMs. Você nunca é notificado das próprias ações.
• Rotas de canal — administradores da organização criam rotas (/v1/plan/notification-routes/) que publicam os tipos da organização escolhidos (uma tarefa concluída, uma atualização de projeto, uma troca de líder…) em um canal de chat, para todo o espaço de trabalho ou para alguns quadros ou projetos. Cada rota tem um registro de entregas e um envio de teste com ?dry_run=true.
• Relatórios agendados — /v1/plan/reports/ agenda um relatório diário, de início ou de fim de semana nos dias e na hora local que você escolher, para um canal e/ou por e-mail, com prévia sobre dados reais, registro de execuções e envio de teste.
• Resumo diário pessoal — GET / PUT /v1/plan/me/briefing/, mais preview/ e send-test/: no que você deveria trabalhar hoje, por mensagem direta e/ou e-mail.
• Também — GET /v1/plan/channels/ para buscar os canais em que rotas e relatórios podem publicar; anexos de quadro (/v1/plan/boards/{board_id}/attachments/); renomear anexos de tarefas, comentários, projetos e metas; quem reagiu a um comentário ou a uma atualização de projeto, e reações em atualizações de projeto.

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

• Caminho base. Todos os endpoints do Dailybot Plan vivem em /v1/plan/…, com os scopes tasks:read / tasks:write / tasks:admin e os eventos de webhook tasks.*. Não existe outro prefixo.
• CLI 4.0.0 — todo comando do Plan vive em dailybot plan <tasks|task|board|project|goal> …. Novos grupos tasks notifications|routes|reports|briefing|channels e filtros por projeto e marco em tasks timeline. Índice de comandos: CLI do Dailybot para o Plan.

2026-09-25 · Adicionado — Filtro de menções na caixa de entrada (Plan Beta)

• Menções — GET /v1/plan/inbox/?mentioned=true mantém só os eventos em que alguém mencionou você, com count e paginação exatos. Combina com type (E).
• Selos por aba — GET /v1/plan/inbox/unread-count/ aceita os mesmos filtros mentioned e type, então o selo de cada aba conta exatamente as linhas dela. Sem parâmetros a resposta não muda. Os dois endpoints recusam parâmetros não declarados com 400 invalid_filter_value.

2026-09-29 · Alterado — uma API key pessoal age como sua pessoa em todo o Plan (Plan Beta)

• Uma API key pessoal é a sua pessoa. Ela vê o que a pessoa vê (incluindo os quadros privados dos quais participa), me é a pessoa, e as escritas são registradas como a pessoa. Pode fazer tudo o que a pessoa pode fazer em cada endpoint do Plan, incluindo projetos, quadros, colunas, metas, marcos, membros, participantes, silenciar, visualizações salvas e anexos. Não é preciso um papel de administrador da organização nem conceder scopes; os scopes tasks:* explícitos da key são um teto escolhido pela pessoa (tasks:write cobre as operações de administração, tasks:read é somente leitura).
• Keys de agente e da organização não mudam. Nunca agem como uma pessoa: 403 insufficient_scope nos endpoints que exigem uma pessoa, 400 actor_required em owner=me. Convidados continuam recusados com 403 guest_not_allowed, com uma key ou uma sessão.
• Os quadros ganham effective_visibility (org ou members): um quadro dentro de um projeto members lê members. Objetos privados são 404 not found para quem não tem um grant.
• CLI 3.19.0: --agent-name / DAILYBOT_AGENT_NAME, task brief, e um token de login ligado ao host da API que o emitiu. 3.19.1: orientação mais clara de invalid_agent_attribution. 3.20.0: uma API key pessoal pode fazer tudo o que sua pessoa pode fazer no Plan, e task labels foi corrigido. 3.21.0: comandos de marcos e atualizações: project milestone-attach, milestone-attachments, milestone-attachment get|rename|delete, milestone-restore, update-get, update-edit, update-delete, update-attach, update-attachments e update-attachment get|rename|delete. 3.22.0: a CLI cobre todas as operações do Plan em produção: task comment-react|comment-unreact, board label update|delete, board visit, tasks recents, tasks attachments-resolve e task comment --reply-to <uuid-do-comentário>. Também reforça o logout (logout revoga todas as sessões) e os nomes dos arquivos baixados. Veja Autenticação do Plan e Atribuição de agente.

2026-09-29 · Adicionado — Marcos e atualizações de projeto (Plan Beta)

• Marcos e atualizações de projeto — novo POST …/milestones/{milestone_id}/restore/; anexos em marcos e em atualizações de projeto (GET|POST(multipart, até 5 MiB) …/attachments/, GET|PATCH(renomear)|DELETE …/attachments/{attachment_id}/ e GET …/attachments/{attachment_id}/content/); e GET|PATCH|DELETE …/updates/{update_id}/. Referencie os arquivos com marcadores attachment:{uuid}. Os marcos ganham attachment_count; as atualizações trazem executed_by_agent, provenance, edited_at e attachments. Somente quem escreveu uma atualização a edita ou anexa arquivos a ela (403 update_not_author, um código novo); a pessoa autora ou um administrador da organização a exclui. Envie agent_name para coescrever uma atualização com um agente.

2026-09-29 · Adicionado — Atribuição de agente no Plan (Plan Beta)

• Nomeie o agente em uma escrita — todo endpoint de /v1/plan/ que altera dados aceita agent_name em um corpo JSON, ou o header X-Dailybot-Agent-Name (UTF-8 codificado em percent-encoding) em escritas multipart e sem corpo. O corpo vence; o máximo é de 128 caracteres, e um nome maior ou impossível de decodificar é 400 invalid_agent_attribution. Uma key do tipo agente que o enviar recebe o mesmo erro. O selo nunca altera uma resposta de permissão.
• Respostas — comentários, anexos e itens de atividade trazem executed_by_agent ({uuid, name, username, avatar} ou null); uma tarefa ganha executors (do mais recente ao mais antigo, com first_at e last_at), separado do executor singular.
• Keys — uma API key pessoal age como sua pessoa (veja a entrada acima). Objetos privados continuam 404 para quem não foi convidado. Veja Atribuição de agente.

2026-09-26 · Alterado — Permissões open-org do Plan (Plan Beta)

• Todo membro não convidado tem tasks:read, tasks:write e tasks:admin. Membros podem criar metas, projetos e quadros (e gerenciar estados e associações). tasks:admin significa escritas de contêineres — já não é só admin da org. Convidados continuam recusados com 403 guest_not_allowed antes do entitlement.
• O convite é a alavanca de acesso. A privacidade é a associação, não o papel da organização. Contêineres de toda a organização são um espaço compartilhado. Um projeto ou quadro members é 404 (não visível) sem grant. Convide uma pessoa ou uma equipe; o último grant em um contêiner privado é 409 last_grant_cannot_be_removed. Não há papéis por projeto (lead/viewer).
• Supervisão: administradores da organização e managers de todos os times podem ver todos os projetos; um quadro members ainda precisa de um grant.
• API keys da organização continuam sem tasks:admin — não podem alterar quem vê (associação) nem quem é notificado (participantes) (403 insufficient_scope).
• PATCH /v1/plan/projects/{project_id}/ persiste visibility e concede automaticamente ao ator que privatiza (org → members). Veja Autenticação do Plan.

2026-09-25 · Adicionado — Anexos em comentários, metas e projetos (Plan Beta)

• Anexos de comentários — GET/POST /v1/plan/tasks/{task_id}/comments/{comment_id}/attachments/, GET …/{attachment_id}/content/ e DELETE …/{attachment_id}/. Somente o autor do comentário anexa; quem enviou, o autor do comentário ou um administrador da organização podem remover. As linhas de comentários agora trazem attachments, os anexos prontos por posição.
• Anexos de projetos e metas — as mesmas quatro operações em /v1/plan/projects/{project_id}/attachments/ e /v1/plan/goals/{goal_id}/attachments/. Qualquer pessoa que possa ver o projeto ou a meta pode listar e baixar; enviar e remover exigem um membro não convidado com sessão iniciada e tasks:admin (todo membro não convidado o tem; uma API key recebe 403 insufficient_scope).
• Regras de envio — somente multipart/form-data (file, caption opcional), até 5 MiB (400 attachment_too_large com extra.max_size_bytes), os mesmos tipos de arquivo dos anexos de tarefas e no máximo 50 por comentário, projeto ou meta. Os downloads transmitem os bytes com nosniff e no-store. Referencie uma imagem em uma descrição como attachment:{uuid} e resolva-a com o url assinado da lista, que expira em 15 minutos.
• Atividade — task.comment_attached, task.comment_detached, goal.attached, goal.detached, project.attached e project.detached aparecem na atividade; não são eventos de webhook.

2026-09-25 · Segurança + Adicionado + Alterado — API do Dailybot Plan (Beta)

• Segurança: as keys são recusadas em toda operação tasks:admin — criar, editar, arquivar e restaurar projetos, quadros, estados do fluxo de trabalho e metas, reordenar estados, gerenciar os membros de quadros e projetos e vincular metas a projetos exigem um membro não convidado com sessão iniciada (tasks:admin; todo membro não convidado o tem após o login). Uma API key da organização recebe 403 insufficient_scope. Veja os endpoints somente para pessoas. Em parte supersedido pela mudança open-org de 2026-09-26 acima (membros, não só admins da org).
• Segurança: o seletor de menções não retorna mais endereços de e-mail — as linhas de GET /v1/plan/boards/{board_id}/mentionables/ são {uuid, name, handle, avatar_url, has_photo, kind}, sem e-mail, e q corresponde a um nome, um handle ou um id externo, nunca a um endereço de e-mail completo.
• Adicionado: a criação em lote pode ir para o topo — POST /v1/plan/tasks/bulk/ com operation: create aceita um position opcional: start coloca as novas tarefas no topo de cada coluna, na ordem dos itens; end (o padrão) as mantém no fim.
• Adicionado: o seletor de menções traz avatares — cada linha agora tem avatar_url (texto ou null) e has_photo, com o mesmo significado que no responsável de uma tarefa: quando has_photo é false, mostre as iniciais. Em uma linha agent eles são null e false.
• Alterado: as operações com simulação documentam sua prévia — arquivar um projeto, quadro, estado do fluxo de trabalho, tarefa ou meta, e concluir um marco, respondem um DryRunPreview com ?dry_run=true: {operation, dry_run, reversible, restore_path, consequence, affects}, mais would_refuse e refusal_code ao arquivar um estado do fluxo de trabalho. O lote mantém sua própria prévia.
• Alterado: a simulação em lote informa todas as mudanças — POST /v1/plan/tasks/bulk/?dry_run=true agora lista em changes as mudanças de labels, rank, estimate e start_date.

2026-09-25 · Adicionado — API do Dailybot Plan (Beta)

• API do Plan, em beta — 117 operações em /v1/plan/ para projetos, metas, quadros, estados, tarefas, comentários, anexos, favoritos, visualizações salvas, atividade, caixa de entrada, linha do tempo e busca. Tudo em /v1/plan/ está marcado como Beta e pode mudar antes da disponibilidade geral. Até sua organização ser habilitada, os endpoints do Plan respondem 402 plan_upgrade_required; escreva para [email protected] para participar.
• Tela inicial em uma requisição — GET /v1/plan/pulse/ aceita include=projects,attention,activity,goal_progress, e a resposta indica sua população com scope: "viewer_visible".
• Atualizações de projetos em lote — GET /v1/plan/projects/updates/ retorna as atualizações mais recentes de todos os projetos que você pode ver.
• Minhas tarefas — GET /v1/plan/me/tasks/counts/ adiciona by_scope com {total, open, overdue, blocked}, e o filtro state de GET /v1/plan/me/tasks/ aceita uuids de estado ou open / done.
• Simulação em lote — POST /v1/plan/tasks/bulk/?dry_run=true executa a chamada e a desfaz.
• Leituras mais rápidas — As leituras do Plan estão mais rápidas, com as mesmas respostas.
• Feed de mudanças — since em GET /v1/plan/boards/{board_id}/delta/ é um alias obsoleto de updated_since; envie updated_since. Nenhuma data de remoção foi anunciada.

Documentado em /pt/developers/plan e nos seis grupos do Plan da referência da API.

2026-08-25 · Adicionado — CLI Etiquetas/Featured, DMs a equipes aprovadoras e aprovações programáticas

• CLI e Agent Skill — dailybot label … e dailybot featured … envolvem Etiquetas e Featured (dailybot-cli >= 3.9.0). Sub-skills dailybot-labels e dailybot-featured.
• Aprovação — fan-out por equipe — Se um formulário lista uma equipe como aprovadora, cada membro ativo recebe a mensagem Aprovar/Rejeitar no chat (DM do Slack).
• Aprovação — API / CLI — POST /v1/forms/{uuid}/responses/{uuid}/approval/ com action_status e comment opcional. CLI: dailybot form response approve|deny.
• Web app — Aprovadores de equipe podem agir no modal quando a API expõe user_can_approve.

Documentado em /pt/developers/cli, /pt/developers/agent-skill e /pt/developers/api/forms.

2026-08-03 · Adicionado — Etiquetas organizacionais, personalização e comentários de aprovação

• Etiquetas organizacionais — CRUD público em /v1/labels/ mais atribuição POST em formulários, automações e check-ins. Elegível quando o recurso está habilitado e o chamador não é convidado; convidados negados. Filtros labels= (pelo menos uma das etiquetas selecionadas / OR), featured=, prioritize_featured=true. labels: LabelSummary[] e is_featured (privado) em linhas de listagem (e no detalhe de Formulários).
• Personalização (/v1/me/...) — Preferências de dashboard, visões salvas e Featured. Não exige elegibilidade de Etiquetas.
• Comentários de fluxo de aprovação — approval_flow_comments_enabled (somente leitura nos payloads). Comentário opcional curto na web (acima do limite é rejeitado); modal no Slack. Microsoft Teams, Discord e Google Chat não coletam comentários de aprovação pelo chat hoje — use a web. Configure na UI Setup — não via PATCH .../config/.
• Enriquecimento de listagens — quando indisponível, params de enriquecimento → 503 dashboard_enrichment_temporarily_unavailable. Códigos em /pt/developers/errors.

Documentado em /pt/developers/api/labels, /pt/developers/api/users, /pt/developers/api/forms, /pt/developers/api/check-ins e /pt/developers/api/workflows.

2026-07-23 · Adicionado — Contrato de botões interativos v3.1: Modal → Workflow + {{trigger.*}}

modal_body agora se compõe com callback_workflow (além de callback_url). No envio, os valores dos campos do modal são entregues ao workflow api_trigger disparado como {{trigger.fields.<name>}}. Os passos do workflow ganham o namespace canônico {{trigger.*}} (source, body.*, button_id, button_value, fields.*, clicked_at, user.*, triggered_by_user_uuid) para ramificação por valor de botões e pré-preenchimento de formulários modal-para-workflow. As credenciais callback_auth de botões / request_auth de workflows são somente escrita (leituras retornam máscara ***).

Documentado em /pt/developers/api/messaging e /pt/developers/api/workflows.

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

Novo tipo de trigger de workflow disparado apenas de fora do motor: o endpoint público de trigger (202 Accepted, execução async, payload JSON opcional ≤8 KiB) ou o callback_workflow de um botão interativo (resolve exclusivamente para workflows ativos api_trigger). Selecionável no construtor de automações como When triggered via API or button. Os erros incluem workflow_not_triggerable, workflow_trigger_payload_invalid, workflow_execute_not_allowed e workflow_frozen.

Documentado em /pt/developers/api/workflows.

2026-07-23 · Adicionado — request_auth na ação de workflow Send-a-Request

O passo de automação SEND_REQUEST aceita autenticação estática opcional com a mesma forma que callback_auth de botões interativos — bearer, basic ou custom_header (token RFC 7230; nomes de header reservados negados). Os valores suportam {{variables}}; credenciais nunca aparecem nas saídas do passo.

Documentado em /pt/developers/api/workflows (padrões de trigger + auth) e /pt/developers/api/messaging (callback_auth).

2026-07-23 · Adicionado — Contrato de botões interativos v3: callback_prompt, callback_workflow, response, callback_auth

Quatro adições ao envelope de botões de /v1/send-message/: (1) callback_command é um slot de comando conhecido (≤200 chars); prompts de IA em texto livre passam para callback_prompt (≤2000, executa como o clicador) — o prefixo "prompt: …" é rejeitado com 400 button_callback_command_invalid; (2) callback_workflow (UUID de workflow) dispara um workflow interno; (3) response anexa uma auto-resposta a qualquer botão (ack instantâneo em paralelo com callback_url, botões aninhados recursivos com limites de profundidade/tamanho); (4) callback_auth adiciona auth de transporte estática opcional aos POSTs de callback — aditivo à assinatura HMAC sempre ativa. A exclusividade mútua abrange os cinco callbacks.

Documentado em /pt/developers/api/messaging.

2026-07-23 · Adicionado — Botões interativos: callback_url, modal_body, callback_form, callback_command (778e5d6cd)

Um botão interactive pode disparar POSTs de saída assinados para callback_url (HMAC-SHA256, estilo Stripe X-Dailybot-Signature: t=…, v1=…, janela de replay de 5 minutos, chave de idempotência X-Dailybot-Delivery), abrir um modal de plataforma a partir de modal_body, abrir um formulário interno do Dailybot via callback_form, ou executar um comando conhecido via callback_command. Cada botão interativo carrega um id gerado pelo servidor $btn/<uuid>. Google Chat é entregue como plataforma hangouts. Aditivo — os caminhos legacy payload.callback_config / action continuam funcionando.

Documentado em /pt/developers/api/messaging.

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/agents.

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/agents.

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.