APIs, Interoperabilidade e Contratos de Integração

Quando classificar um caso como LS-04

Use a LS-04 quando a disputa nasce da fronteira entre dois sistemas de partes diferentes — uma API, um webhook, um arquivo de intercâmbio. Pergunta de enquadramento: "o dano decorre de algo que atravessou uma interface entre sistemas de responsáveis distintos?" Se o problema é interno a um único fornecimento, provavelmente é LS-01.

Tipologia (com critério)

• LS-04.1 — Indisponibilidade × SLA. A API ficou fora do ar ou degradada além do pactuado. O litígio exige medir disponibilidade real e confrontar com a definição contratual de "indisponível".
• LS-04.2 — Alteração unilateral da interface. Endpoint, formato de resposta, autenticação ou rate limit mudaram sem o aviso pactuado, quebrando o consumidor.
• LS-04.3 — Dados incorretos/incompletos. A API respondeu, mas errado — e o sistema consumidor decidiu com base no erro.
• LS-04.4 — Responsabilidade em cadeia. Falha do provedor A quebra o sistema de B e causa dano ao cliente C. A perícia precisa localizar o elo causal.

Protocolo executável — 5 etapas

1. Etapa 1 — Congelamento do contrato de interface.
   Objetivo: fixar o que a API prometia à época dos fatos.
   Insumos: documentação da API (OpenAPI/Swagger, GraphQL schema, PDFs), changelogs, termos de uso, SLA contratual.
   Execução: obter a versão da documentação vigente NA ÉPOCA (Wayback Machine, repositórios de docs, e-mails com anexos); comparar com a versão atual; registrar diffs.
   Entregável: "contrato de interface" da época × atual, com as mudanças destacadas.
2. Etapa 2 — Coleta de logs dos dois lados.
   Objetivo: reconstruir as chamadas reais.
   Insumos: logs do consumidor (aplicação, gateway, APM) e, quando obtível, do provedor (por acordo ou ordem judicial).
   Execução: extrair requisições do período: timestamp, endpoint, status code, latência, payload (com cuidado de dados pessoais/LGPD), headers de rate limit; preservar com hash.
   Entregável: dataset de chamadas do período litigioso.
3. Etapa 3 — Reprodução controlada.
   Objetivo: demonstrar o comportamento alegado de forma verificável.
   Execução: reproduzir as chamadas problemáticas em ambiente controlado, documentando request + response com gravação; quando a API já mudou, demonstrar com os logs da Etapa 2 e o diff da Etapa 1.
   Entregável: roteiro de reprodução com evidência audiovisual/log.
4. Etapa 4 — Medição de SLA e análise causal.
   Objetivo: quantificar o descumprimento e localizar a causa.
   Execução: calcular disponibilidade/latência real com base nos logs e na definição contratual (janelas de manutenção contam? erro 429 conta?); para a cadeia (LS-04.4), montar o diagrama de dependências e posicionar a primeira falha; separar falha do provedor × implementação incorreta do consumidor (retry ausente, timeout mal configurado) × infraestrutura (DNS, rede).
   Entregável: planilha de SLA + diagrama causal com o elo responsável.
5. Etapa 5 — Laudo/Parecer.
   Execução: traduzir: "a interface prometia X (doc da época), passou a fazer Y (diff/logs), sem o aviso de Z dias (cláusula), e isso causou a parada do módulo W do contratante (logs correlacionados)".
   Entregável: laudo com linha do tempo da falha e responsabilidade fundamentada.

Checklist do advogado

• Guardar a documentação da API da ÉPOCA (print, PDF, Wayback) — ela some;
• Preservar logs do próprio cliente imediatamente (retenção costuma ser de 30–90 dias!);
• Avaliar exibição judicial dos logs do provedor cedo — eles também expiram.

Erros comuns

• Deixar expirar a retenção de logs — o caso morre por falta de prova;
• Medir SLA sem a definição contratual de indisponibilidade;
• Ignorar a hipótese de erro do próprio consumidor (falta de retry/fallback) — a contradita vai explorá-la.

Base legal

CC arts. 389, 422, 475. Marco Civil (Lei 12.965/14) — guarda de registros. LGPD (Lei 13.709/18) quando os payloads contêm dados pessoais. Cláusulas de SLA, aviso prévio de breaking change e limitação de responsabilidade.

Quesitos-modelo

• "Queira o Sr. Perito calcular, com base nos logs preservados e na definição contratual de indisponibilidade, o percentual de disponibilidade da API no período X–Y, confrontando-o com o SLA pactuado."
• "Queira o Sr. Perito informar se houve alteração no formato de resposta do endpoint Z entre as datas A e B, se houve comunicação prévia conforme a cláusula N, e qual o efeito da alteração sobre o sistema do Requerente."