Glossário de IDs e enums

Muitos campos dos commands da LightHouse API são inteiros com semântica de negócio — por exemplo, "statusId": 1 ou "tipoAnomalia": 3. Este glossário explica cada campo, identifica os enums declarados no spec e indica o endpoint para consultar valores válidos quando eles variam por empresa.

ExecutorId vs. EmitenteId vs. UsuarioId

Filtros de relatório e listagem por pessoa (/v1/reports/*, /v1/atividades, /v3/ocorrencias) usam três IDs de usuário com significados diferentes — confundi-los é o erro mais comum ao montar essas chamadas.

Campo	Significado	Quando usar
ExecutorId	Quem executou/resolveu a atividade ou ocorrência	Pergunta é sobre algo solucionado, resolvido ou executado por alguém
EmitenteId	Quem abriu/registrou a ocorrência	Pergunta é sobre algo aberto, criado ou emitido por alguém
UsuarioId	Filtro genérico por usuário, sem distinguir papel	Intenção não está clara, ou o endpoint não distingue executor/emitente

Regra de bolso: solucionou → ExecutorId; abriu → EmitenteId.

Para descobrir o ID de uma pessoa a partir do nome: GET /v1/usuarios?Search=<nome> — o ID está no campo usuario da resposta. Ver o fluxo completo em Perguntas de negócio.

Campos com enum fixo declarado no spec

O spec OpenAPI declara esses tipos como type: integer com lista fechada de valores. Os labels (nomes de cada valor) não estão no spec — a coluna "Significado" abaixo documenta a semântica conhecida pelo domínio.

---

plataforma

Aparece em: SaveOcorrenciaCommand · SaveCorrecaoCommand · BaixaAtividadeCommand
Tipo no spec: EPlataforma — enum inteiro [0, 1, 2, 3, 4, 5, 6, 7, 9, 10]
Valor recomendado para integrações via API: 6

Identifica a origem da requisição. Use sempre o inteiro — não envie a string "WEB" ou "API".

O campo Plataform do login no AuthCenter (ver Autenticação → Obtendo o token) usa o mesmo enum — testado: 6 (API) funciona em ambos.

Valor	Significado
6	API — use este valor para integrações server-side
1	WEB (interface web)
0,2,3,4,5,7,9,10	Outros canais internos — consulte o time AuthCenter

---

statusId — baixa de atividade

Aparece em: BaixaAtividadeCommand
Tipo no spec: EStatusAtividade — enum inteiro [1, 2, 3, 4, 5]

Resultado da execução da tarefa. Para marcar como não realizada, informe também justificativaNaoRealizado (ver seção abaixo).

Valor	Significado
1	Realizada
2	Não realizada
3	Em andamento
4	Cancelada
5	— (reservado)

---

statusAprovacaoId

Aparece em: AprovarOcorrenciaCommand
Referência no spec: EStatusAprovacao — enum inteiro [1, 2, 3, 4]

Correção — a tabela anterior estava errada

Os valores abaixo foram corrigidos em 05/07/2026, confirmados em EStatusAprovacao.cs e empiricamente. A versão anterior desta tabela invertia aprovação e rejeição: quem enviasse statusAprovacaoId=1 acreditando estar aprovando deixava a ocorrência pendente (AguardandoAprovacao), sem aprovar nem rejeitar nada.

Valor	Nome canônico	Significado
1	AguardandoAprovacao	Aguardando decisão — não é aprovação
2	Aprovado	É este o valor para aprovar
3	Rejeitado	Rejeitado
4	AprovadoAutomaticamente	Aprovado automaticamente (workflow da empresa)

---

statusAvaliacaoId

Aparece em: AprovarOcorrenciaCommand (obrigatório ao aprovar — ver nota na receita de resolução)
Tipo no spec: EAvaliacoes — enum inteiro [1, 2, 3, 4], confirmado no código-fonte

Avaliação qualitativa da execução, registrada no momento da aprovação:

Valor	Nome canônico
1	Bom
2	Ruim
3	Satisfatorio
4	NaoSeAplica

---

conformidade

Aparece em: BaixaAtividadeCommand
Tipo no spec: EConformidade — enum inteiro [1, 2, 3]

Valor	Significado
1	Conforme
2	Não conforme
3	— (reservado)

---

avaliacao

Aparece em: BaixaAtividadeCommand
Tipo no spec: EAvaliacoes — enum inteiro [1, 2, 3, 4]

Mesmo enum de statusAvaliacaoId (Bom/Ruim/Satisfatorio/NaoSeAplica) — aqui aplicado à avaliação da execução da tarefa, não da aprovação de ocorrência.

---

tipo — evento de geolocalização

Aparece em: RegistrarEventoLocalizacaoCommand
Tipo no spec: ETipoEventoLocalizacao — enum inteiro [1, 2, 3]

Tipo do evento de localização registrado pelo executor em campo.

---

StatusIds / status — ocorrências (v3)

Aparece em: parâmetro de query StatusIds de GET /v1|v2|v3/ocorrencias e GET /v1|v3/ocorrencias/count; campo de resposta status das listagens.
Tipo no spec: EStatusOcorrencia — enum inteiro [1, 2, 3, 4, 5], confirmado no código-fonte (EStatusOcorrencia.cs) e testado no sandbox:

Valor	Nome canônico	Significado prático
1	Analisada	Ocorrência em aberto/em tratamento — é o filtro para "abertas"
2	Solucionada	Resolvida
3	NaoAnalisada	Registrada, ainda não analisada
4	Inativa	Inativada
5	Expirada	Prazo expirado

"Quantas ocorrências abertas?" = GET /v3/ocorrencias/count com header EmpresaId + StatusIds=1.

statusNome é um label híbrido — nunca use como chave de filtro/agrupamento

Para filtrar ou agrupar programaticamente, use sempre o inteiro status. O campo de resposta statusNome não é um simples label do inteiro:

• Para status 3 (NaoAnalisada) e 5 (Expirada), statusNome vem da própria tabela de status.
• Para status 1 (Analisada), 2 (Solucionada) e 4 (Inativa), statusNome vem do tipo da última correção (tipoUltimaCorrecao) — por isso um mesmo status=1 aparece com nomes diferentes ("Gerado O.S", "Agendada", "Aguardando Material" etc.), conforme a última correção aplicada.

tipoUltimaCorrecao referencia ETipoCorrecao, que tem uma base de sistema [1, 3, 4, 5, 6, 7, 14] (EmAndamento=1, Solucionada=3, Agendada=4, AguardandoAutorizacao=5, Autorizada=6, GeradoOs=7, NaoAutorizada=14) — mas cada empresa pode configurar tipos adicionais (ex.: 15 observado no sandbox). Consulte GET /v3/correcoes/tipos para os tipos efetivamente configurados na empresa, em vez de assumir só a base do sistema.

⚠️ Limitação atual confirmada: use um único valor por vez em StatusIds (ex.: StatusIds=1). Passar múltiplos valores (por repetição do parâmetro ou lista separada por vírgula) não filtra como OR — o comportamento com múltiplos valores está em verificação com o time de backend. Até lá, para consultar mais de um status, faça uma chamada por valor.

O parâmetro equivalente em atividades, StatusId (singular, obrigatório em GET /v1/atividades), também está declarado como "type": "string" sem enum no spec — mesma ressalva de formato se aplica, valores ainda não testados.

---

Campos com valores dinâmicos (configurados por empresa)

Esses campos variam por empresa — os IDs válidos dependem da configuração do back-office de cada cliente. Consulte o endpoint indicado antes de montar o payload.

Campo	Command	Descrição	Como obter os valores válidos
tipoAnomalia	SaveOcorrenciaCommand	Tipo de ocorrência da empresa	GET /v1/tiposocorrencias → campo tipoAnomalia (int) + nome
anomaliaTipicaId	SaveOcorrenciaCommand	Ocorrência típica pré-configurada	GET /v3/ocorrencias/tipicas/{empresaId}
prioridadeAnomaliaId	SaveOcorrenciaCommand	Prioridade da ocorrência	GET /v1/prioridadesocorrencias?unidadeId={id} → campo prioridadeAnomalia (int) + descricao + cor — unidadeId é obrigatório (query); sem ele a API retorna 400 estruturado
tipoCorrecaoId	SaveCorrecaoCommand	Tipo de ação corretiva	GET /v3/correcoes/tipos (header EmpresaId necessário — sem ele, [] silencioso) → campo codigo (int) + nome
justificativaNaoRealizado	BaixaAtividadeCommand	Justificativa para tarefa não realizada	GET /v1/atividades/justificativas → campo justificativaTarefa (int) + descricao
regras de preenchimento	SaveOcorrenciaCommand	Quais campos são obrigatórios pela empresa	GET /v3/ocorrencias/config/{empresaId}

Para tipoCorrecaoId, o spec também declara ETipoCorrecao [1, 3, 4, 5, 6, 7, 14] como valores-base do sistema. O endpoint GET /v3/correcoes/tipos retorna os tipos efetivamente configurados por empresa — use sempre o endpoint.

GET /v1/prioridadesocorrencias exige unidadeId

Testado: sem o query param unidadeId, a API retorna 400 estruturado. unidadeId é o mesmo identificador que aparece como siteId nos commands de ocorrência (SaveOcorrenciaCommand) — Unidade e Site são o mesmo conceito, só com nomes diferentes entre endpoints. Exemplo: GET /v1/prioridadesocorrencias?unidadeId=26098.

GET /v3/correcoes/tipos exige o header EmpresaId [F12]

Testado: sem o header EmpresaId, a resposta é [] silenciosamente (sem erro) — mesmo padrão de falha silenciosa de outros endpoints desta API. A resposta traz dois identificadores por item, com propósitos diferentes:

• codigo — a semântica do tipo. É este o valor que vai em tipoCorrecaoId no POST /v3/correcoes.
• tipoAcaoCorretivaEmpresa — o ID único do registro configurado pela empresa (não é o que o SaveCorrecaoCommand espera).

⚠️ Uma empresa pode ter vários tipos configurados com o mesmo codigo (registros distintos, mesma semântica) — não assuma que codigo é único por empresa; use-o só para decidir qual tipoCorrecaoId enviar, não como chave de busca de um registro específico.

---

Consultas de discovery antes de criar registros

Para uma IA ou integração, o padrão recomendado é fazer as consultas de referência uma vez por sessão/empresa e cachear os resultados:

# Tipos de ocorrência da empresa
curl "https://lighthousev2.lkp.app.br/v1/tiposocorrencias" \
  -H "Authorization: Bearer SEU_TOKEN"

# Prioridades configuradas (unidadeId é obrigatório)
curl "https://lighthousev2.lkp.app.br/v1/prioridadesocorrencias?unidadeId=26098" \
  -H "Authorization: Bearer SEU_TOKEN"

# Regras e campos obrigatórios da empresa
curl "https://lighthousev2.lkp.app.br/v3/ocorrencias/config/123" \
  -H "Authorization: Bearer SEU_TOKEN"

# Tipos de ação corretiva (EmpresaId no header é necessário)
curl "https://lighthousev2.lkp.app.br/v3/correcoes/tipos" \
  -H "Authorization: Bearer SEU_TOKEN" \
  -H "EmpresaId: 123"

# Justificativas de atividade não realizada
curl "https://lighthousev2.lkp.app.br/v1/atividades/justificativas" \
  -H "Authorization: Bearer SEU_TOKEN"

Use os inteiros retornados diretamente nos campos correspondentes dos commands.