Sinistros

Participar e acompanhar sinistros de um condomínio — os danos que dão origem a um processo com uma seguradora.

Os sinistros são sempre geridos no GC

Ao contrário das ocorrências, um sinistro é assunto da empresa de condomínios e nunca do centro de manutenção. Estes pontos funcionam da mesma forma e com todos os campos em qualquer empresa, independentemente do que o ping indicar para as ocorrências.

Sinistros e ocorrências são conjuntos separados

Um sinistro não aparece em /occurrences, e uma ocorrência não aparece em /claims. Os identificadores também não se misturam: pedir um sinistro pelo identificador de uma ocorrência responde 404, e ao contrário também.

Se acompanha os dois, percorra as duas listagens e sincronize as duas correntes de alterações, cada uma com o seu cursor.

Listar sinistros

GET /claims

Permissão · occurrences:read

Parâmetros

Os mesmos da listagem de ocorrências: idBuilding, status, idTaskStatus, idMaintenanceNature, idServiceType, idPriority, idFraction, openedFrom, openedTo, limit, cursor e include.

Todos funcionam sempre — não há aqui filtros recusados conforme a empresa.

Pedido

bash

curl "https://servidor.exemplo/api/integrations/v1/acme/claims?idBuilding=12&status=open" \
  -H "ApiKey: $GC_API_KEY"

Resposta · `200`

A mesma forma de uma ocorrência, com Source sempre a GC:

json

{
  "Items": [
    {
      "Source": "GC",
      "Id": 612,
      "Reference": "2026/0612",
      "IdBuilding": 12,
      "BuildingCode": "0012",
      "OpeningDate": "2026-09-18T00:00:00",
      "ClosingDate": null,
      "Status": { "Id": 1, "Description": "Em aberto" },
      "Closed": false,
      "Priority": { "Id": 2, "Description": "Alta" },
      "Nature": { "Id": 9, "Description": "Danos por água" },
      "ServiceType": { "Id": 7, "Description": "Canalização" },
      "IdFraction": 340,
      "FractionCode": "A",
      "IdClient": 87,
      "Description": "Rebentamento de conduta no 2.º piso, com danos na fração A.\n\nSinistro\nApólice: AP-2024-889112\nTipo de seguro: Multirriscos\nSeguradora: Seguradora Exemplo, S.A.\nMediador: Mediação Exemplo, Lda.\nParticipação: SIN/2026/4471",
      "HasAttachment": true,
      "LastActivityDate": "2026-09-22T10:41:00"
    }
  ],
  "Paging": { "Limit": 100, "NextCursor": null, "HasMore": false }
}

Os campos são os de uma ocorrência — ver a tabela completa.

Os dados do seguro estão no texto, não em campos

Repare na Description: os dados da apólice, da seguradora, do mediador e do número de participação são acrescentados ao fim do texto, num bloco iniciado por Sinistro. Não existem como campos próprios.

Se precisa deles estruturados, guarde-os do seu lado quando participa o sinistro — extraí-los do texto é frágil e não é o que a API promete.

Erros

Os mesmos da listagem de ocorrências, sem o 502: os sinistros nunca dependem de outro sistema.

Obter um sinistro

GET /claims/{idClaim}

Permissão · occurrences:read

Parâmetros

Parâmetro	Tipo	Descrição
`idClaim`	inteiro	No caminho
`include`	texto	`interventions` para trazer o histórico

Pedido

bash

curl "https://servidor.exemplo/api/integrations/v1/acme/claims/612?include=interventions" \
  -H "ApiKey: $GC_API_KEY"

Erros

Estado	Código	Quando
`400`	`UNSUPPORTED_INCLUDE`	`include` diferente de `interventions`
`401` · `403`		Ver Autenticação e Permissões
`404`	`CLAIM_NOT_FOUND`	Não existe, ou é uma ocorrência — essas leem-se em `/occurrences`

Participar um sinistro

POST /claims

Permissão · occurrences:write · aceita Idempotency-Key

Corpo

Os mesmos campos de abrir uma ocorrência, mais o objeto Insurance, que é obrigatório:

Campo de `Insurance`	Tipo	Descrição
`IdPolicy`	inteiro	A apólice registada. Ver Apólices
`PolicyNumber`	texto	Número da apólice, para uma apólice não registada aqui
`InsurerName`	texto	Seguradora, para uma apólice não registada aqui
`ClaimNumber`	texto	Número de participação junto da seguradora
`IncidentDate`	data e hora	Quando ocorreu o dano

Pedido

Com a apólice registada — o número, a seguradora e o mediador são retirados dela:

bash

curl -X POST "https://servidor.exemplo/api/integrations/v1/acme/claims" \
  -H "ApiKey: $GC_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
        "BuildingCode": "0012",
        "IdFraction": 340,
        "IdClient": 87,
        "IdMaintenanceNature": 9,
        "IdServiceType": 7,
        "IdPriority": 2,
        "Description": "Rebentamento de conduta no 2.º piso, com danos na fração A.",
        "Insurance": {
          "IdPolicy": 21,
          "ClaimNumber": "SIN/2026/4471",
          "IncidentDate": "2026-09-18T07:30:00"
        }
      }'

Para uma apólice que não esteja registada no GC, envie os campos soltos:

json

"Insurance": {
  "PolicyNumber": "AP-2024-889112",
  "InsurerName": "Seguradora Exemplo, S.A.",
  "ClaimNumber": "SIN/2026/4471",
  "IncidentDate": "2026-09-18T07:30:00"
}

Quando dá IdPolicy, os dados da apólice prevalecem sobre os campos soltos.

Resposta · `201`

json

{ "Source": "GC", "Id": 612, "Reference": "2026/0612" }

A data do dano

O IncidentDate é o que abre o registo — e não o dia em que foi participado. É por essa data que o sinistro é depois procurado, que é o que interessa a um processo com uma seguradora.

Peça também as apólices já terminadas

Um sinistro é frequentemente participado contra a apólice em vigor à data do dano, que pode já não ser a de hoje. Use includeExpired=true em /buildings/{id}/insurance-policies ao escolher a apólice.

Erros

Estado	Código	Quando
`400`	`INVALID_BODY`	Corpo em falta ou JSON inválido
`400`	`MISSING_FIELD`	Falta `Insurance`, ou um campo obrigatório da ocorrência
`400`	`MISSING_DESCRIPTION`	Falta a descrição do que aconteceu
`400`	`INVALID_REFERENCE`	A apólice não existe, ou não pertence a este condomínio
`401` · `403`		Ver Autenticação e Permissões
`404`	`BUILDING_NOT_FOUND` · `FRACTION_NOT_FOUND`	O condomínio ou a fração não existem
`409`	`IDEMPOTENCY_KEY_REUSED`	A chave já foi usada noutro pedido
`422`	`CLAIMS_NOT_CONFIGURED`	A empresa não tem os sinistros configurados
`422`	`MAINTENANCE_NOT_LICENSED`	A empresa não tem o módulo de manutenção

CLAIMS_NOT_CONFIGURED resolve-se na aplicação

Um sinistro é uma tarefa de um tipo marcado como tal, e essa marcação é feita pela empresa na aplicação. Enquanto não existir, não há onde registar um sinistro. Não se resolve repetindo o pedido — apresente-o ao utilizador como configuração em falta.

Tratar um sinistro

Depois de participado, um sinistro trata-se pelos mesmos pontos de uma ocorrência, com o seu identificador:

Operação	Caminho
Atribuir	`POST /occurrences/{idClaim}/assignment`
Registar intervenção	`POST /occurrences/{idClaim}/interventions`
Alterar estado ou prioridade	`PATCH /occurrences/{idClaim}`
Descarregar anexo	`GET /occurrences/{idClaim}/attachment`

Só a leitura é que tem caminhos próprios, para manter as duas listagens separadas. As escritas são as mesmas — ver Ocorrências.

Acompanhar alterações

GET /claims/changes

Corrente própria, separada da das ocorrências. Ver Sincronização incremental.

Sinistros ​

Sinistros e ocorrências são conjuntos separados ​

Listar sinistros ​

Parâmetros ​

Pedido ​

Resposta · 200 ​

Erros ​

Obter um sinistro ​

Parâmetros ​

Pedido ​

Erros ​

Participar um sinistro ​

Corpo ​

Pedido ​

Resposta · 201 ​

A data do dano ​

Erros ​

Tratar um sinistro ​

Acompanhar alterações ​

Sinistros

Sinistros e ocorrências são conjuntos separados

Listar sinistros

Parâmetros

Pedido

Resposta · `200`

Erros

Obter um sinistro

Parâmetros

Pedido

Erros

Participar um sinistro

Corpo

Pedido

Resposta · `201`

A data do dano

Erros

Tratar um sinistro

Acompanhar alterações