APIs operacionais¶
Padrão de acesso¶
O console usa um proxy interno para chamar os serviços da operação. As telas devem consumir contratos estáveis e tratar ausência de dados como estado operacional, não como falha visual.
Rotas principais¶
| Recurso | Método | Caminho | Uso |
|---|---|---|---|
| Saúde | GET | /api/assurant/health |
Verificar disponibilidade. |
| Parâmetros de roteamento | GET | /api/assurant/routing/parameters |
Exibir regras vigentes. |
| Processar sinistro | POST | /api/assurant/routing/process |
Selecionar assistência. |
| Casos históricos | GET | /api/assurant/routing/historical-cases |
Escolher caso já processado para validação. |
| Assistências | GET | /api/assurant/service-centers |
Listar SCs para mapa, seleção e fallback. |
| Audit log | GET | /api/assurant/audit-log |
Consultar trilha de eventos. |
| Indicadores | GET | /api/assurant/audit-log/pnl |
Consultar métricas agregadas. |
Tratamento de erro¶
401ou sessão expirada: voltar para login comfrom.404em recurso opcional: exibir estado vazio.500em operação crítica: mostrar mensagem acionável e manter navegação.- Falha de rede: preservar dados já carregados quando possível.
Boas práticas de contrato¶
- Não depender de strings de interface para lógica.
- Validar campos opcionais antes de renderizar.
- Não usar dados fictícios como fallback operacional.
- Registrar ações críticas com contexto suficiente para auditoria.