Migalhas de Peso

Falha de API: O que o contrato decide antes e depois do incidente

A falha de um componente que você não desenvolveu pode virar conta no seu nome. Diante do consumidor, responde a empresa; entre empresas, vale o contrato. Veja o que definir antes da falha.

19/6/2026
Publicidade
Expandir publicidade

Uma loja virtual integra um gateway de pagamento para processar cartões. Numa quinta-feira de movimento, o gateway fica instável por algumas horas e parte das compras é recusada sem motivo aparente. O cliente final desiste, a loja perde vendas e ainda recebe reclamações. Quando a poeira baixa, sobra a pergunta que ninguém gosta de fazer: a falha foi de quem fornece a API, mas quem paga essa conta?

A cena se repete em formatos diferentes. Um cálculo de frete que volta errado e gera prejuízo no envio. Um serviço antifraude que aprova uma transação que deveria ter barrado. Uma API de mensageria que não dispara a confirmação e o pedido se perde. Em todos esses casos existe um componente de terceiro no meio do caminho e existe um cliente que sofreu um dano concreto. A resposta jurídica é menos direta do que apontar o dedo para quem desenvolveu a API.

Não existe apenas uma relação jurídica

O primeiro equívoco é tratar o problema como se houvesse uma única relação envolvida. Em geral existem pelo menos duas, e cada uma segue uma lógica própria.

De um lado, há o contrato entre a sua empresa e quem fornece a API. É uma relação entre dois agentes econômicos, normalmente regida pelas regras gerais do CC e pelo que as partes negociaram. De outro, há o contrato (mesmo que não exista um documento escrito e assinado) entre a sua empresa e o seu cliente, aquele que efetivamente usou o seu produto ou serviço. Dependendo de quem é esse cliente, a relação pode atrair o CDC ou permanecer no terreno do CC.

Quem desenha a integração costuma pensar só na primeira relação, a técnica, e esquece que a segunda é a que define a exposição real ao risco. O fornecedor da API quase nunca aparece para o cliente final. Para esse cliente, quem prometeu o serviço foi a sua empresa, e é a sua empresa que ele vai procurar.

Quando o cliente é consumidor, a empresa responde

Se quem sofreu o prejuízo é um consumidor, a posição da sua empresa fica mais delicada. O CDC adota a responsabilidade objetiva do fornecedor de serviços pelos defeitos na prestação (art. 14). O consumidor não precisa provar culpa. Basta demonstrar o defeito, o dano e o nexo entre os dois.

O detalhe que costuma surpreender é que a origem do defeito em uma API contratada de terceiro não afasta essa responsabilidade. Para o consumidor, o fornecedor é quem ele contratou. A cadeia de fornecimento responde de forma solidária (arts. 7º, parágrafo único, e 25, § 1º), o que permite ao consumidor escolher contra quem dirigir a cobrança, e ele tende a escolher quem está mais perto e mais visível. Há, inclusive, regra específica para esse cenário: quando o dano decorre de um componente incorporado ao produto ou serviço, respondem solidariamente quem realizou a incorporação e quem forneceu o componente (art. 25, § 2º). Uma API embutida no seu serviço se enquadra bem nessa lógica.

Há ainda um limite relevante. Em relação de consumo, é nula a cláusula que exonere ou atenue a obrigação de indenizar (arts. 25 e 51, I). Não adianta inserir no contrato com o consumidor uma frase dizendo que a empresa não responde por falhas de terceiros, porque diante dele essa frase tende a não produzir efeito. Existe uma exceção que interessa a quem vende para outras empresas: quando o consumidor é pessoa jurídica, a indenização pode ser limitada em situações justificáveis.

É importante lembrar: limitar com critério é possível; eliminar a responsabilidade, não.

Entre empresas, prevalece o que o contrato definiu

Quando o cliente também é uma empresa e usa o seu serviço como insumo da própria atividade, a lógica muda. Em regra, sai de cena o CDC e entra o CC, com responsabilidade de natureza contratual. A pergunta deixa de ser "houve defeito?" e passa a ser "o que as partes combinaram a respeito?".

O CC parte da premissa de que, não cumprida a obrigação, o devedor responde por perdas e danos (art. 389), o que abrange tanto o que a outra parte efetivamente perdeu quanto o que deixou de ganhar (art. 402). Entre empresas, porém, há ampla liberdade para distribuir esse risco no contrato. É lícito limitar valores, escalonar penalidades e definir hipóteses de exclusão, desde que respeitadas a boa-fé objetiva e a função social do contrato (arts. 421 e 422).

Cabe um alerta. A fronteira entre relação empresarial e relação de consumo nem sempre é nítida. Quando a empresa contratante é tecnicamente vulnerável e figura como destinatária final do serviço, há decisões do judiciário que aplicam o CDC, mesmo entre pessoas jurídicas. Por isso, presumir que "é uma relação entre empresas, então o CDC não entra" é uma aposta que pode sair cara.

A força maior raramente socorre quem escolheu o fornecedor

A defesa mais comum depois de um incidente é alegar caso fortuito ou força maior. O CC de fato afasta a responsabilidade nessas hipóteses, salvo se a parte houver assumido esse risco no contrato (art. 393). O problema é que nem toda falha se encaixa nesse conceito.

A doutrina e a jurisprudência costumam distinguir o fortuito externo do fortuito interno. O externo é o evento estranho à atividade, imprevisível e inevitável. O interno é o risco que faz parte do próprio negócio, ainda que decorra de conduta de terceiro. A escolha de um fornecedor de API e a decisão de construir o seu produto sobre aquele componente são, em boa medida, risco do seu negócio. A falha de uma peça que você escolheu integrar dificilmente será tratada como algo externo e alheio à sua atividade.

Vale separar os contextos. Diante do consumidor, esse raciocínio pesa com força, porque a responsabilidade é objetiva e a saída pela força maior é estreita. Entre empresas, o próprio art. 393 admite que as partes assumam ou afastem esse risco no contrato, de modo que o desfecho depende mais do que foi pactuado do que do rótulo dado ao evento.

Isso não quer dizer que a força maior nunca se aplique. Uma indisponibilidade generalizada de infraestrutura, um desastre ou um evento realmente fora do alcance das partes podem se enquadrar. Mas a régua é alta, e contar com esse argumento como plano principal costuma terminar em frustração.

O direito de regresso e a conta que sobra

Mesmo quando a sua empresa paga o cliente, a história não termina ali. Quem indeniza tem direito de regresso contra quem efetivamente deu causa ao dano. Esse direito tem dupla base: entre responsáveis solidários, o art. 283 do CC assegura a quem pagou por inteiro exigir dos demais a parte de cada um; e, na relação com o fornecedor da API, é o contrato que define como e quanto se recupera.

O ponto sensível está no descompasso entre as duas pontas. A obrigação diante do cliente, sobretudo se for consumidor, pode ser ampla e difícil de limitar. Já a recuperação diante do fornecedor costuma estar limitada pelo contrato que a sua empresa assinou, muitas vezes a um teto modesto, como o valor pago nos últimos meses de serviço. O resultado prático é uma conta que sobra: você responde por inteiro lá na frente e recupera apenas uma fração aqui atrás. Esse intervalo, e não a discussão sobre a culpa, é o que costuma gerar o prejuízo que ninguém havia previsto.

O que vale definir em contrato antes da falha

O melhor momento para tratar dessa exposição é antes de a integração entrar em produção, e o instrumento é o contrato, nas duas pontas.

No contrato com o seu cliente, vale descrever com honestidade o que o serviço entrega e em que condições. Compromissos de disponibilidade precisam ser realistas, porque prometer o que depende de terceiros é assumir um risco que não está inteiramente nas suas mãos. Onde a lei permitir, limites bem redigidos de responsabilidade e de força maior dão previsibilidade. Diante do consumidor, esse espaço é mais estreito e não chega a afastar a obrigação de indenizar.

No contrato com o fornecedor da API, o esforço de negociação tende a valer ainda mais. Convém buscar um acordo de nível de serviço (que normalmente chamamos de SLA) com metas claras e consequências reais pelo descumprimento, além de uma responsabilidade proporcional à sua exposição efetiva, e não apenas à devolução de mensalidades. Importam também a obrigação de o fornecedor arcar com reclamações de terceiros decorrentes de falha dele, prazos mínimos de aviso antes de mudanças que quebrem a integração e regras de continuidade e portabilidade de dados. São esses pontos que mudam o desfecho de um incidente de indisponibilidade.

Existe ainda a camada operacional, que o direito não substitui. Mecanismos de contingência, monitoramento, registro detalhado dos incidentes e uma escolha de fornecedor minimamente documentada não evitam toda falha, mas tornam muito mais fácil provar o que aconteceu e de onde partiu, tanto para se defender quanto para exercer o regresso.

Antes de integrar, vale ler o contrato

A resposta para "quem responde quando a integração quebra" raramente é uma só. Diante do cliente, em especial do consumidor, costuma responder a empresa que ofereceu o produto, mesmo que a falha tenha nascido em uma API que ele nunca viu. Entre a sua empresa e o fornecedor, vale o que foi negociado, e é aí que se decide quanto dessa conta retorna à origem.

Integrar serviços de terceiros é parte natural de construir tecnologia hoje, e não há nada de errado nisso. O que costuma faltar é tratar esse arranjo também como uma decisão jurídica, e não apenas técnica. O contrato é a ferramenta para distribuir o risco antes de a falha ocorrer. Depois dela, a conversa já é sobre quem paga.

Autor

Luiz Felipe Fortes dos Santos Gehlen Advogado (OAB/SC 78.602), DPO e consultor em direito digital, proteção de dados e segurança da informação, com mais de uma década em tecnologia e software.

Veja mais no portal
cadastre-se, comente, saiba mais

Artigos Mais Lidos