Pular para o conteúdo principal

Receita: dar baixa em atividades em lote

Objetivo

Marcar várias tarefas de manutenção preventiva como realizadas de uma só vez, em uma única chamada.

Pré-requisitos​

  • Token JWT válido (ver Autenticação).
  • Os IDs das tarefas a baixar (descobertos no Passo 1).
  • Base URL produção: https://lighthousev2.lkp.app.br · sandbox: https://lighthouse.lkp.dev.br.

Os exemplos -d '{...}' abaixo são bash/POSIX. No PowerShell, use o padrão de arquivo — ver Primeiros passos → PowerShell.

Passo 1 — Listar as atividades agendadas​

Encontre as tarefas pendentes para o site/período. Parâmetros obrigatórios: SelectedDate e StatusId. Envie EmpresaId conforme o contrato do endpoint (ver referência).

curl "https://lighthousev2.lkp.app.br/v1/atividades?SelectedDate=2026-06-29&StatusId=1&SiteId=456" \
  -H "Authorization: Bearer SEU_TOKEN"
Listagem de atividades — parâmetros (validado 07/2026)

GET /v1/atividades exige StatusId (ex.: StatusId=1) e uma referência de data (SelectedDate + DiasAdicionais, faixa 1–40). Com um usuário escopado a uma única empresa (Administrador/Operacional — o tipo padrão de qualquer integração), a listagem funciona normalmente. (Observação técnica: tokens com acesso a múltiplas empresas simultaneamente podem encontrar erro por escopo de unidade não resolvido — não é o caso do integrador padrão, que sempre opera escopado a uma única empresa.)

Filtros opcionais relevantes: ExecutorId, AreaId, GrupoAreaId, PlanoAtividadeId, DiasAdicionais, PageIndex, PageSize (consulte a referência para a lista completa). Cada item traz seu id de tarefa.

Passo 2 — (Opcional) Conferir informações da baixa​

Antes de baixar, valide os dados das tarefas selecionadas:

curl -X POST "https://lighthousev2.lkp.app.br/v2/atividades/baixa/list" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '[101, 102, 103]'

(o corpo é a lista de IDs de tarefa).

Passo 3 — Dar baixa em lote​

Esta receita usa PUT /v2/atividades/baixa (BaixaAtividadeEmLoteCommand) — contrato confirmado a partir dos nomes reais do DTO, não pela mensagem de erro (que é enganosa, ver abaixo).

Contrato da baixa em lote v2 (validado 07/2026)

PUT /v2/atividades/baixa (BaixaAtividadeEmLoteCommand) — o contrato não é intuitivo:

  • O array de tarefas é ParametrosBaixaAtividades — não Tarefas nem tarefasIds. A mensagem de erro do backend fala em "Tarefas", mas isso é só o rótulo da mensagem; o campo do JSON é ParametrosBaixaAtividades. Enviar Tarefas resulta em 400 dizendo que a tarefa "deve ser informada" mesmo com ela preenchida.
  • Cada item do array: { "TarefaId": <int>, "Realizada": <bool> }. Realizada precisa ser true explícito — se omitir, a atividade é baixada como não realizada.
  • Campos de raiz obrigatórios: SiteId e Plataforma (além de DataRealizada).
curl -X PUT "https://lighthousev2.lkp.app.br/v2/atividades/baixa" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "SiteId": 32552,
    "DataRealizada": "2026-05-15T10:00:00",
    "Plataforma": 1,
    "ParametrosBaixaAtividades": [
      { "TarefaId": 1030080657, "Realizada": true }
    ]
  }'

Use POST /v2/atividades/baixa/info (body: array de IDs de tarefa) para obter a estrutura de referência antes de montar a baixa: retorna atividades[].tarefaId, aplicacaoPlanoAtividade, aplicacao.site, tempoTotalPrevisto, qrCodeObrigatorio.

Baixa via API pode falhar com 500 (defeito conhecido 07/2026)

Há um defeito de backend em correção: a baixa grava a plataforma a partir do token, e tokens obtidos pelo fluxo padrão de autenticação podem gerar 500 (conflito de FK de plataforma). Até a correção, a baixa em lote via API pode não completar mesmo com o payload correto acima.

PUT /v1/atividades/baixa (BaixaAtividadeCommand — tarefasIds e plataforma obrigatórios) existe como rota alternativa, com contrato próprio e incompatível — não são intercambiáveis; confira qual versão sua integração usa antes de montar o payload.

Passo 4 — (Opcional) Registrar medições e fotos​

Se as atividades exigem leitura/medição ou comprovação fotográfica:

Medições — SaveMedicoesAtividadeCommand. Campos obrigatórios: tarefaId e medicoes (array de MedicaoAtividadeCommand):

curl -X POST "https://lighthousev2.lkp.app.br/v1/atividades/medicoes" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "tarefaId": 101,
    "medicoes": [
      {
        "tarefaMedicaoId": 10,
        "atividadeMedicaoId": 20,
        "valorMedicao": 42.5
      }
    ]
  }'

Fotos/Observação — SaveFotoObservacaoAtividadeCommand (nenhum campo é obrigatório, mas tarefaId é a chave de vínculo):

curl -X POST "https://lighthousev2.lkp.app.br/v1/atividades/fotosobservacao" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "empresaId": 123,
    "tarefaId": 101,
    "observacao": "Lubrificação aplicada conforme plano",
    "fotos": []
  }'

Resumo do fluxo​

listar atividades (SelectedDate+StatusId) → (conferir) → PUT baixa em lote v2 (SiteId+Plataforma+ParametrosBaixaAtividades[]) → (medições/fotos)

Dicas para IA / integração​

  • Consulte o Glossário de IDs e enums para os valores válidos de statusId, plataforma, justificativaNaoRealizado e conformidade.
  • A baixa em lote v2 é uma única chamada com ParametrosBaixaAtividades como array — não faça um loop de chamadas individuais. Não confunda com Tarefas/tarefasIds (nomes de outros contratos).
  • Cada item de ParametrosBaixaAtividades precisa de Realizada: true explícito para marcar como realizada.
  • SiteId e Plataforma são obrigatórios em PUT /v2/atividades/baixa — sem SiteId, "Unidade deve ser informada".
  • SelectedDate e StatusId são parâmetros obrigatórios em GET /v1/atividades — omiti-los retorna erro de validação.
  • statusId e justificativaNaoRealizado são códigos de negócio: para marcar como "não realizado", informe a justificativa (consulte GET /v1/atividades/justificativas).
  • tempoTotal é em minutos.
  • Endpoints de escrita afetam dados reais — teste no ambiente Sandbox.