Termos de uso de API: modelo completo e simples

TERMOS DE USO DA API [NOME DA API]

Versão: [número da versão]. Vigente desde: [data]. Versões anteriores: [link para o histórico de versões].

FORNECEDOR: [razão social], inscrita no CNPJ sob o nº [número], com sede na [endereço completo com CEP], titular da plataforma [nome do serviço] e da interface de programação descrita nestes termos, disponível em [endereço do portal do desenvolvedor], e-mail [e-mail], encarregado pelo tratamento de dados pessoais [nome ou empresa], e-mail [e-mail].

DESENVOLVEDOR: a pessoa física maior de 18 anos ou a pessoa jurídica que cria uma conta no portal do desenvolvedor e aceita estes termos. Quando o cadastro é feito em nome de empresa, quem clica em aceitar declara ter poderes para representá-la, e a empresa indicada no cadastro fica vinculada.

Nota: termos de uso de API são aceitos por clique, sem negociação. Por isso o documento identifica o fornecedor, o encarregado e a versão logo no topo. A versão e a data de vigência provam qual regra valia no dia de um bloqueio ou de uma cobrança, e o histórico público evita discussão sobre o texto que o desenvolvedor aceitou.

Cláusula 1ª. Aceite e relação com outros documentos

1.1. Ao criar a conta, gerar uma chave de API ou fazer a primeira requisição, o DESENVOLVEDOR declara que leu e aceitou estes termos e os documentos abaixo, que fazem parte deles:

• a Documentação técnica publicada no portal do desenvolvedor;
• a Política de Uso Aceitável da plataforma, em [link];
• a Política de Privacidade do FORNECEDOR, em [link];
• o Acordo de Tratamento de Dados (DPA), em [link], quando houver tratamento de dados pessoais por conta do DESENVOLVEDOR;
• os Anexos I a IV destes termos.

1.2. Se o DESENVOLVEDOR contratar plano corporativo por proposta ou pedido de compra assinado, as condições comerciais do pedido prevalecem sobre estes termos naquilo em que forem diferentes. No restante, valem estes termos.

1.3. Em caso de conflito entre documentos, prevalece, nesta ordem: o pedido de compra assinado, o DPA quanto a dados pessoais, estes termos, a Política de Uso Aceitável e a Documentação.

Nota: o aceite por clique só vincula se o desenvolvedor teve oportunidade real de ler o texto antes de usar a API. Em relação de consumo, o CDC diz que o contrato não obriga sem esse conhecimento prévio (art. 46). Guarde o registro do aceite: conta, data, hora, IP e versão aceita. A ordem de prevalência evita que um anexo técnico contradiga o preço negociado com um cliente grande.

Cláusula 2ª. Definições

2.1. Nestes termos, as palavras abaixo têm o seguinte sentido:

• API: a interface de programação [nome da API], com seus endpoints, webhooks, SDKs, bibliotecas e ambientes de teste (sandbox);
• Chave de API: o token, segredo, certificado ou credencial OAuth emitido para identificar a Aplicação nas requisições;
• Aplicação: o software, site, aplicativo ou integração do DESENVOLVEDOR que acessa a API;
• Usuário Final: a pessoa que usa a Aplicação;
• Dados da API: as informações que a API devolve ao DESENVOLVEDOR;
• Dados do Desenvolvedor: as informações que o DESENVOLVEDOR envia à API;
• Limite de Requisição: o número máximo de chamadas por unidade de tempo;
• Cota: o volume de uso incluído no plano em cada período de cobrança;
• Versão: o conjunto de endpoints e comportamentos identificado por número, na forma do Anexo III;
• Mudança Incompatível: a alteração que exige do DESENVOLVEDOR mudar o código da Aplicação para continuar funcionando, como remover endpoint, campo obrigatório ou forma de autenticação.

Nota: a definição de mudança incompatível é a peça que sustenta as cláusulas de versão e de descontinuação. Sem ela, o fornecedor pode dizer que nenhuma mudança exige aviso, e o desenvolvedor pode dizer que toda mudança exige. Separar Dados da API e Dados do Desenvolvedor também organiza a propriedade intelectual e a LGPD mais adiante.

Cláusula 3ª. Objeto e licença de uso

3.1. O FORNECEDOR concede ao DESENVOLVEDOR licença limitada, não exclusiva, intransferível, sem direito de sublicenciar e revogável nos termos destas condições, para acessar a API e integrá-la à Aplicação, durante a vigência destes termos e dentro do plano contratado.

3.2. Não fazem parte destes termos, salvo contratação à parte por escrito:

• desenvolvimento, hospedagem ou manutenção da Aplicação;
• consultoria de integração ou suporte dedicado além do previsto no Anexo II;
• garantia de resultado comercial obtido com a Aplicação;
• acesso ao código-fonte da API ou da plataforma.

Nota: a licença é de uso, não de cessão. Cada adjetivo tem função: não exclusiva permite atender concorrentes do desenvolvedor; intransferível impede que ele repasse a chave a terceiro; sem sublicença impede a revenda. Listar o que fica fora reduz a expectativa de que o fornecedor vai construir a integração junto com o cliente.

Cláusula 4ª. Cadastro, conta e enquadramento do Desenvolvedor

4.1. O DESENVOLVEDOR fornecerá dados verdadeiros e atualizados no cadastro, inclusive nome ou razão social, CPF ou CNPJ, e-mail técnico e e-mail financeiro, e manterá esses dados corretos durante a vigência.

4.2. No cadastro, o DESENVOLVEDOR informará se usa a API [como destinatário final, para uso próprio / como insumo de produto ou serviço que oferece a terceiros]. Essa informação não afasta direitos que a lei garanta, mas orienta o atendimento e a cobrança.

4.3. Uma pessoa ou empresa pode manter mais de uma conta apenas para separar ambientes ou projetos, nunca para somar cotas gratuitas ou contornar limites.

Nota: o enquadramento importa porque muda a lei aplicável. Quem usa a API como destinatário final pode ser consumidor (CDC, art. 2º), com as proteções contra cláusulas abusivas. Quem usa a API como insumo do próprio negócio tende a ficar sob o Código Civil, em que os contratos empresariais se presumem paritários (art. 421-A). A declaração ajuda a provar o contexto, sem mudar a natureza da relação.

Cláusula 5ª. Credenciais e chaves de API

5.1. As Chaves de API são pessoais da conta e confidenciais. O DESENVOLVEDOR se obriga a:

• guardar as chaves em servidor ou cofre de segredos, sem incluí-las em código executado no navegador, em aplicativo distribuído ao público ou em repositório aberto;
• usar uma chave por Aplicação e por ambiente (teste e produção);
• trocar as chaves a cada [90] dias ou no prazo indicado na Documentação;
• revogar de imediato a chave de quem deixar a equipe ou o fornecedor de software contratado;
• avisar o FORNECEDOR em até [24] horas depois de saber ou suspeitar de vazamento, pelo canal do Anexo IV.

5.2. As requisições feitas com a Chave de API do DESENVOLVEDOR são presumidas dele, inclusive para cobrança, até o aviso de vazamento previsto no item 5.1. Depois do aviso, o FORNECEDOR revogará a chave em até [2] horas, e o uso posterior não será cobrado.

5.3. O FORNECEDOR pode revogar ou trocar uma chave sem aviso prévio quando detectar exposição pública, uso anormal ou risco à segurança, comunicando o DESENVOLVEDOR logo em seguida.

Nota: chave vazada em repositório público costuma gerar cobrança inesperada e acesso indevido a dados. A presunção do item 5.2 protege o fornecedor, mas tem limite: depois do aviso, a conta não pode continuar pagando pelo uso de terceiros. Em relação de consumo, a presunção pode ser afastada por prova em contrário, e o juiz interpreta a cláusula a favor do consumidor (CDC, art. 47).

Cláusula 6ª. Limites de requisição e cotas

6.1. Cada plano tem Limite de Requisição e Cota descritos no Anexo I. Ao atingir o Limite de Requisição, a API devolverá resposta de excesso de requisições (código HTTP 429), e a Aplicação deverá aguardar o tempo indicado antes de tentar de novo.

6.2. Ao atingir a Cota do período, o FORNECEDOR [bloqueará novas requisições até o próximo período / cobrará o excedente pelo preço do Anexo I / reduzirá a velocidade de resposta], conforme a opção do plano informada no Anexo I.

6.3. O DESENVOLVEDOR não poderá distribuir requisições entre várias contas ou chaves, nem usar qualquer outro meio, para ultrapassar os limites do seu plano.

6.4. O FORNECEDOR poderá alterar limites e cotas com aviso de [30] dias. A redução de limite de plano pago já contratado só vale a partir da renovação seguinte, salvo motivo de segurança ou exigência legal, hipótese em que o DESENVOLVEDOR poderá encerrar o plano sem multa e receber de volta o valor proporcional já pago.

Nota: limites protegem a infraestrutura e a experiência dos outros clientes, e o Anexo I evita que o desenvolvedor só os descubra no primeiro erro 429. A cláusula de alteração é a mais sensível: reduzir limite de plano pago no meio do período equivale a mudar o preço de forma unilateral, o que o CDC proíbe (art. 51, X e XIII). Por isso a redução só alcança a renovação ou abre saída sem multa.

Cláusula 7ª. Uso permitido

7.1. O DESENVOLVEDOR pode usar a API para integrar a Aplicação à plataforma [nome do serviço] e oferecer funcionalidades aos Usuários Finais, dentro da finalidade descrita na Documentação e do plano contratado.

7.2. O DESENVOLVEDOR pode guardar em cache os Dados da API pelo prazo máximo de [24 horas / prazo indicado em cada endpoint], salvo autorização por escrito ou indicação diferente na Documentação.

7.3. Para usos de alto volume, para marketplaces de integrações ou para Aplicações que atendam outras empresas como intermediárias, o DESENVOLVEDOR deve contratar o plano [parceiro / corporativo].

Nota: dizer o que é permitido evita a leitura de que tudo o que não está proibido é livre. O prazo de cache controla o risco de o desenvolvedor montar uma cópia da base do fornecedor, e a regra de intermediação separa o desenvolvedor comum do parceiro que revende integrações para muitas empresas.

Cláusula 8ª. Uso proibido

8.1. É proibido ao DESENVOLVEDOR, diretamente ou por terceiros:

• extrair dados da plataforma por raspagem (scraping), robôs ou automação de interface, fora dos endpoints da API;
• revender, alugar, sublicenciar ou disponibilizar a API ou as Chaves de API a terceiros, inclusive como serviço de repasse de requisições;
• fazer engenharia reversa, descompilar ou tentar obter o código-fonte da API, dos SDKs ou da plataforma, salvo nos casos em que a lei autorize;
• contornar limites, autenticação, medição de uso ou qualquer medida técnica de proteção;
• usar os Dados da API para montar base de dados que substitua a plataforma ou para desenvolver produto que concorra diretamente com o [nome do serviço];
• usar os Dados da API para treinar modelos de inteligência artificial, salvo autorização por escrito;
• fazer testes de carga, de invasão ou de vulnerabilidade sem autorização prévia por escrito;
• enviar código malicioso, conteúdo ilícito ou dados pessoais sem base legal;
• apresentar a Aplicação como produto oficial do FORNECEDOR ou usar suas marcas fora do previsto na Cláusula 17ª;
• usar a API em violação da Política de Uso Aceitável ou da lei.

8.2. O DESENVOLVEDOR pode publicar comparativos de desempenho (benchmarks) somente se informar a metodologia, a data do teste e a versão usada, e der ao FORNECEDOR oportunidade de comentar antes da publicação.

Nota: as proibições de scraping e de base substituta protegem a base de dados, que a Lei 9.610/1998 resguarda quando sua organização é criação intelectual (arts. 7º, XIII, e 87). A ressalva dos casos em que a lei autorize preserva as exceções da Lei 9.609/1998. A vedação de concorrência alcança só o uso dos Dados da API: proibir o desenvolvedor de atuar no mercado seria desproporcional.

Cláusula 9ª. Obrigações do Desenvolvedor perante os Usuários Finais

9.1. O DESENVOLVEDOR é o único responsável pela Aplicação e pela relação com os seus Usuários Finais, e se obriga a:

• manter termos de uso e política de privacidade próprios, com informação clara de que a Aplicação usa a API de terceiro;
• obter as autorizações e cumprir as bases legais necessárias para enviar dados pessoais à API;
• prestar atendimento aos Usuários Finais, sem direcioná-los ao suporte do FORNECEDOR;
• não fazer promessa aos Usuários Finais sobre a disponibilidade da API que vá além do Anexo II.

9.2. Quando a Aplicação permitir que Usuários Finais acessem dados da conta deles na plataforma do FORNECEDOR, o acesso dependerá de autorização do próprio usuário, pelo fluxo de consentimento previsto na Documentação, e poderá ser revogado por ele a qualquer tempo.

Nota: o fornecedor não tem relação direta com o cliente do desenvolvedor. Esta cláusula deixa claro quem informa, quem atende e quem responde perante o usuário final. O item 9.2 descreve o modelo de autorização delegada (como OAuth), em que o titular decide qual aplicação acessa a conta dele, o que ajuda a demonstrar transparência perante a LGPD.

Cláusula 10ª. Disponibilidade e nível de serviço

10.1. Para os planos pagos, o FORNECEDOR se compromete com a disponibilidade mensal e os créditos descritos no Anexo II. Os planos gratuitos, de teste e as funcionalidades identificadas como beta não têm garantia de disponibilidade.

10.2. Não contam como indisponibilidade:

• manutenções programadas avisadas com [48] horas de antecedência no painel de status;
• respostas de limite excedido (HTTP 429) causadas pelo uso acima do plano;
• suspensão aplicada com base nestes termos;
• falhas da Aplicação, da rede do DESENVOLVEDOR ou de serviços de terceiros que ele escolheu;
• caso fortuito ou força maior.

10.3. Os créditos do Anexo II compensam a indisponibilidade sem impedir o DESENVOLVEDOR de buscar perdas e danos nos limites da Cláusula 24ª, e [não se aplicam / também se aplicam] a quem for consumidor.

Nota: Entre empresas, o crédito como compensação principal é aceito, porque a alocação de riscos deve ser respeitada (CC, art. 421-A, II). Em relação de consumo, cláusula que exonera ou atenua a responsabilidade por vício do serviço é nula (CDC, art. 51, I), e o crédito não pode ser o único remédio dele. Veja o SLA para SaaS para calibrar os números.

Cláusula 11ª. Suporte, painel de status e comunicação técnica

11.1. O suporte técnico segue os canais, horários e prazos de primeira resposta do Anexo II. Para o plano gratuito, o suporte é feito apenas pela documentação e pelo fórum da comunidade.

11.2. O FORNECEDOR mantém painel de status público em [endereço], com incidentes em andamento, manutenções programadas e histórico dos últimos [90] dias.

11.3. Avisos técnicos, como novas versões, descontinuações e mudanças de limite, serão enviados ao e-mail técnico do cadastro e publicados no registro de alterações (changelog) da Documentação.

Nota: o painel de status vira prova de disponibilidade para os dois lados. Exigir que o desenvolvedor mantenha o e-mail técnico atualizado (Cláusula 4ª) e usar esse canal para os avisos dá segurança às cláusulas de versão, descontinuação e alteração dos termos, que dependem de aviso prévio comprovado.

Cláusula 12ª. Versionamento

12.1. A API é identificada por versões, na forma do Anexo III. Mudanças compatíveis, como novos endpoints, novos campos opcionais e correções, podem ser feitas a qualquer tempo, com registro no changelog.

12.2. Mudanças Incompatíveis só serão feitas em nova versão principal. A versão anterior continuará disponível pelo prazo mínimo do Anexo III, contado do aviso de lançamento da nova versão.

12.3. A Aplicação deve tolerar campos novos nas respostas e não pode depender de comportamento não documentado.

12.4. Em caso de vulnerabilidade grave ou de ordem de autoridade, o FORNECEDOR poderá aplicar Mudança Incompatível em prazo menor, informando o motivo e oferecendo alternativa técnica sempre que possível.

Nota: o versionamento é a promessa de estabilidade que o desenvolvedor compra. A regra é simples: o que quebra a integração vem em versão nova, com convivência das duas por um período. O item 12.3 transfere ao desenvolvedor o risco de depender de comportamento que nunca foi prometido. A exceção de segurança precisa ser estreita para não esvaziar a regra.

Cláusula 13ª. Descontinuação e aviso prévio

13.1. O FORNECEDOR poderá descontinuar uma versão, um endpoint ou a API inteira, observados os prazos mínimos de aviso do Anexo III:

• versão principal ou endpoint: [12] meses de aviso, contados do lançamento da alternativa;
• API inteira ou funcionalidade sem substituta: [12] meses de aviso;
• funcionalidade beta ou do plano gratuito: [30] dias de aviso.

13.2. Durante o aviso, o FORNECEDOR manterá a versão ou a API em funcionamento, publicará guia de migração e responderá às dúvidas de migração pelos canais do Anexo II.

13.3. Se a descontinuação atingir funcionalidade paga sem alternativa equivalente, o DESENVOLVEDOR poderá encerrar o plano sem multa e receberá de volta o valor proporcional dos períodos pagos e não usados.

13.4. Os prazos acima podem ser reduzidos apenas por ordem de autoridade, por mudança na lei ou por risco grave de segurança, e o FORNECEDOR informará o motivo.

Nota: quem integra uma API investe meses de desenvolvimento nela. Quando uma parte fez investimentos consideráveis, a denúncia só produz efeito depois de prazo compatível com a natureza e o vulto deles (CC, art. 473, parágrafo único). O aviso longo, o guia de migração e o reembolso proporcional reduzem o risco de indenização.

Cláusula 14ª. Alterações destes termos

14.1. O FORNECEDOR poderá alterar estes termos, publicando a nova versão no portal do desenvolvedor e avisando o e-mail técnico e o e-mail financeiro com antecedência mínima de [30] dias da entrada em vigor.

14.2. O aviso indicará as cláusulas alteradas e um resumo das mudanças. Se o DESENVOLVEDOR não concordar, poderá encerrar a conta antes da data de vigência, sem multa, com devolução proporcional dos valores pagos antecipadamente.

14.3. Alterações exigidas por lei ou por autoridade, ou que apenas beneficiem o DESENVOLVEDOR, podem valer antes do prazo de aviso.

14.4. Alterações de preço seguem a Cláusula 15ª e não se aplicam ao período já pago.

Nota: cláusula que autoriza o fornecedor a modificar o contrato sozinho depois de celebrado é nula em relação de consumo (CDC, art. 51, XIII), assim como a variação unilateral de preço (art. 51, X). Como termos de API mudam com frequência, a saída é combinar aviso prévio, resumo do que mudou e direito de sair sem custo. Entre empresas, o mesmo desenho reduz a discussão sobre boa-fé.

Cláusula 15ª. Planos, tarifação por uso e pagamento

15.1. Os planos, os preços, as franquias e o preço do excedente estão no Anexo I. O uso é medido pelos registros do FORNECEDOR, que ficam disponíveis no painel da conta com detalhamento por dia, endpoint e Chave de API.

15.2. A cobrança é [mensal / anual], [antecipada para a assinatura e posterior para o excedente], por [cartão de crédito / boleto / Pix], com vencimento em [dia]. O FORNECEDOR emitirá nota fiscal de serviço no mês da cobrança.

15.3. O DESENVOLVEDOR poderá contestar a medição em até [30] dias da emissão da fatura, indicando o período e as requisições questionadas. O FORNECEDOR responderá em até [10] dias úteis com os registros correspondentes, e a parte não contestada continua devida.

15.4. Os preços serão reajustados a cada 12 meses pela variação do [IPCA/IBGE], ou por outro índice oficial que o substitua. Mudanças de preço além do reajuste valem a partir da renovação seguinte, com aviso de [60] dias.

15.5. O DESENVOLVEDOR pode configurar no painel um teto de gastos mensal. Atingido o teto, a API passa a recusar requisições cobradas até o próximo período ou até o aumento do teto.

15.6. Os tributos incidentes sobre os serviços estão incluídos no preço, salvo indicação diferente no Anexo I. Retenções exigidas por lei serão aplicadas na forma da legislação.

Nota: na cobrança por uso, a briga quase sempre é sobre a medição. Dar acesso aos registros detalhados e um prazo de contestação transforma a discussão em conferência de dados. O teto de gastos protege contra a conta inesperada causada por erro de código ou chave vazada. O índice de reajuste precisa estar escrito: sem ele, aplica-se o IPCA por força do art. 389, parágrafo único, do Código Civil.

Cláusula 16ª. Atraso no pagamento

16.1. O atraso no pagamento sujeita o DESENVOLVEDOR a:

• multa de 2% sobre o valor em atraso;
• juros de mora de [1% ao mês / pela taxa legal do art. 406 do Código Civil], contados do vencimento;
• atualização monetária pelo IPCA.

16.2. Depois de [15] dias de atraso e de aviso por e-mail com prazo de [5] dias úteis para pagamento, o FORNECEDOR poderá suspender as Chaves de API de produção até a quitação. Os dados do DESENVOLVEDOR não serão apagados durante a suspensão por atraso.

Nota: desde a Lei 14.905/2024, juros não convencionados seguem a taxa legal, igual à Selic menos o IPCA (CC, art. 406, § 1º), com metodologia do Conselho Monetário Nacional divulgada pelo Banco Central (§ 2º). Para juros fixos, escreva o percentual. O CDC limita a multa de mora a 2% nas operações com crédito ao consumidor (art. 52, § 1º), e o mercado usa o mesmo teto.

Cláusula 17ª. Propriedade intelectual e marcas

17.1. A API, a Documentação, os SDKs, a plataforma e as marcas [nome do serviço] pertencem ao FORNECEDOR ou a seus licenciantes. Estes termos não transferem nenhum direito além da licença da Cláusula 3ª.

17.2. A Aplicação e os Dados do Desenvolvedor pertencem ao DESENVOLVEDOR ou a seus licenciantes. O FORNECEDOR usará os Dados do Desenvolvedor apenas para prestar o serviço, cumprir a lei e proteger a plataforma.

17.3. O DESENVOLVEDOR pode usar o nome e o logotipo do FORNECEDOR apenas para informar que a Aplicação se integra ao [nome do serviço], de acordo com as diretrizes de marca em [link], sem sugerir parceria oficial, patrocínio ou certificação.

17.4. Sugestões e comentários sobre a API podem ser usados livremente pelo FORNECEDOR, sem remuneração, sem que isso transfira ao FORNECEDOR a propriedade da Aplicação.

17.5. Componentes de código aberto distribuídos nos SDKs seguem as respectivas licenças, indicadas na Documentação.

Nota: a separação entre o que é do fornecedor (API, documentação, marca) e o que é do desenvolvedor (aplicação, dados enviados) evita a cláusula abusiva que se apropria da criação do cliente. O uso de marca limitado a dizer que integra evita que o desenvolvedor venda a aplicação como produto oficial. Confira as obrigações das licenças open source antes de distribuir SDKs.

Cláusula 18ª. Proteção de dados pessoais

18.1. Os papéis das partes na Lei 13.709/2018 (LGPD) são os seguintes:

• dados de cadastro da conta, registros de acesso e dados de faturamento: o FORNECEDOR é controlador;
• dados pessoais que o DESENVOLVEDOR envia à API para que a plataforma processe em seu nome: o DESENVOLVEDOR é controlador e o FORNECEDOR é operador, e vale o DPA;
• dados pessoais que a API entrega ao DESENVOLVEDOR por autorização do titular ou do cliente da plataforma: o DESENVOLVEDOR é controlador do tratamento que fizer na Aplicação.

18.2. Como operador, o FORNECEDOR tratará os dados apenas segundo as instruções documentadas do DESENVOLVEDOR, que incluem estes termos, o DPA e as chamadas feitas à API, e informará se considerar uma instrução ilegal.

18.3. O FORNECEDOR poderá usar suboperadores de infraestrutura listados em [link], avisando inclusões com [15] dias de antecedência. Transferências internacionais seguirão os mecanismos previstos na LGPD e na regulamentação da Agência Nacional de Proteção de Dados (ANPD).

18.4. Ao término, os dados tratados como operador serão devolvidos pela exportação prevista na Cláusula 28ª e eliminados em até [60] dias, salvo guarda exigida por lei.

18.5. O DESENVOLVEDOR não enviará dados pessoais sensíveis ou de crianças e adolescentes à API, salvo se o plano e a Documentação permitirem esse tratamento de forma expressa.

Nota: controlador é quem decide sobre o tratamento, e operador é quem trata em nome do controlador (LGPD, art. 5º, VI e VII). O operador segue as instruções do controlador (art. 39) e responde solidariamente se descumprir a lei ou essas instruções (art. 42, § 1º, I). Definir papéis por tipo de dado evita tratar o fornecedor como controlador de tudo. Veja o que deve constar no DPA para SaaS.

Cláusula 19ª. Incidentes de segurança

19.1. Se o FORNECEDOR tiver conhecimento de incidente de segurança que afete dados pessoais tratados como operador, avisará o DESENVOLVEDOR em até [48] horas, com as informações disponíveis sobre a natureza dos dados, os titulares afetados, as medidas adotadas e os riscos.

19.2. O DESENVOLVEDOR, como controlador, decide sobre a comunicação à ANPD e aos titulares. O FORNECEDOR cooperará com informações complementares e com as medidas técnicas de contenção.

19.3. Se o incidente ocorrer na Aplicação ou com Chaves de API do DESENVOLVEDOR, ele avisará o FORNECEDOR no prazo da Cláusula 5ª e adotará as medidas de contenção indicadas.

19.4. Quanto aos dados de que é controlador, o FORNECEDOR fará as comunicações exigidas pela lei e pelo regulamento da ANPD.

Nota: o controlador comunica à ANPD e ao titular o incidente que possa acarretar risco ou dano relevante (LGPD, art. 48). O Regulamento de Comunicação de Incidente de Segurança (Resolução CD/ANPD nº 15/2024, arts. 6º e 9º) fixa o prazo de três dias úteis, como informa a página oficial da ANPD. O aviso do operador precisa chegar antes; as 48 horas são sugestão.

Cláusula 20ª. Segurança da informação

20.1. O FORNECEDOR adotará medidas técnicas e administrativas de segurança compatíveis com o estado da técnica, incluindo:

• tráfego da API apenas por conexão criptografada (TLS);
• criptografia dos dados armazenados e controle de acesso por menor privilégio;
• registros de acesso guardados pelo prazo mínimo de 6 meses;
• programa de gestão de vulnerabilidades e canal para relato responsável de falhas em [endereço].

20.2. O DESENVOLVEDOR manterá a Aplicação com controles equivalentes, protegerá os Dados da API que guardar e não fará testes de invasão sem a autorização prevista na Cláusula 8ª.

20.3. Pesquisadores que relatarem vulnerabilidade de boa-fé pelo canal indicado, sem acessar dados além do necessário para demonstrar a falha, não serão alvo de medidas do FORNECEDOR com base nestes termos.

Nota: a LGPD exige medidas de segurança aptas a proteger os dados desde a concepção do serviço (art. 46, caput e § 2º). O prazo de 6 meses para registros de acesso é o mínimo do Marco Civil da Internet para provedores de aplicações constituídos como pessoa jurídica (Lei 12.965/2014, art. 15). O canal de relato responsável incentiva quem encontra falhas a avisar antes de divulgar.

Cláusula 21ª. Confidencialidade

21.1. São confidenciais as Chaves de API, a documentação de acesso restrito, as funcionalidades em teste fechado, os relatórios de segurança e as condições comerciais negociadas em pedido de compra.

21.2. A parte que receber informação confidencial a usará apenas para executar estes termos e a protegerá com o mesmo cuidado que dá às próprias informações, durante a vigência e por [5] anos depois do término.

21.3. Não são confidenciais as informações públicas, já conhecidas pela parte, recebidas de terceiro sem dever de sigilo ou cuja divulgação seja exigida por lei ou ordem de autoridade, com aviso prévio à outra parte quando a lei permitir.

Nota: termos de uso costumam ser públicos, mas parte do relacionamento não é: uma API em teste fechado pode revelar o próximo lançamento, e um relatório de segurança pode servir de mapa para um ataque. A cláusula é curta e recíproca. Para projetos com troca intensa de informação, use um acordo de confidencialidade (NDA) à parte.

Cláusula 22ª. Anticorrupção e conformidade

22.1. As partes cumprirão a Lei 12.846/2013 e as demais normas contra corrupção e lavagem de dinheiro, e não oferecerão, prometerão ou darão vantagem indevida a agente público ou a quem atue em nome dele, direta ou indiretamente.

22.2. O DESENVOLVEDOR não usará a API para fornecer serviços a pessoas ou países sujeitos a sanções que o FORNECEDOR seja obrigado a cumprir, conforme lista em [link].

22.3. A violação desta cláusula autoriza o encerramento imediato da conta, sem prejuízo das medidas legais.

Nota: a Lei Anticorrupção prevê a responsabilização objetiva, administrativa e civil, da pessoa jurídica por atos contra a administração pública (art. 1º). Em APIs usadas por órgãos públicos ou por empresas que vendem ao governo, a cláusula reforça o programa de integridade. Se a sua empresa já tem regras internas, use também a política anticorrupção.

Cláusula 23ª. Garantias e isenções

23.1. Nos planos pagos, o FORNECEDOR garante que a API funcionará de forma substancialmente conforme à Documentação da versão em vigor. Se não funcionar, o FORNECEDOR corrigirá a falha em prazo razoável ou, não sendo possível, o DESENVOLVEDOR poderá encerrar o plano com devolução proporcional.

23.2. O plano gratuito, o ambiente de testes e as funcionalidades beta são oferecidos no estado em que se encontram, sem garantia de funcionamento contínuo ou de adequação a uma finalidade específica, ressalvados os direitos que a lei garanta ao consumidor.

23.3. O FORNECEDOR não garante a exatidão de dados que a API apenas repassa de terceiros ou de fontes públicas, e indicará na Documentação quais endpoints têm essa natureza.

Nota: garantia ampla demais vira promessa de resultado; ausência total de garantia em plano pago tende a ser afastada pelo juiz. O meio-termo é garantir conformidade com a documentação e oferecer correção ou saída. A ressalva dos direitos do consumidor evita que a isenção do plano gratuito seja anulada inteira por excesso (CDC, art. 51, I).

Cláusula 24ª. Limitação de responsabilidade

24.1. Nas relações entre empresas, a responsabilidade total de cada parte por danos decorrentes destes termos fica limitada ao valor pago pelo DESENVOLVEDOR nos [12] meses anteriores ao fato, ou a R$ [valor mínimo], o que for maior.

24.2. Nas relações entre empresas, nenhuma parte responde por lucros cessantes, perda de receita ou dano indireto, salvo se decorrentes de dolo ou culpa grave.

24.3. Os limites acima não se aplicam a:

• dolo ou culpa grave;
• violação de propriedade intelectual;
• violação de confidencialidade ou da Cláusula 18ª, quanto à obrigação de indenizar titulares de dados;
• valores devidos pelo uso da API;
• obrigação de indenizar prevista na Cláusula 25ª.

24.4. Se o DESENVOLVEDOR for consumidor, a responsabilidade do FORNECEDOR segue o Código de Defesa do Consumidor, e esta cláusula não limita direitos que a lei lhe garanta.

Nota: no Código Civil, a alocação de riscos das partes deve ser respeitada (art. 421-A, II e III). No CDC, a cláusula que exonera ou atenua a responsabilidade do fornecedor é nula; com consumidor pessoa jurídica, a indenização pode ser limitada em situações justificáveis (art. 51, I). Por isso o teto vale só entre empresas. Veja a limitação de responsabilidade em SaaS.

Cláusula 25ª. Indenização por reclamações de terceiros

25.1. O DESENVOLVEDOR indenizará o FORNECEDOR pelos valores que este tiver de pagar a terceiros, inclusive Usuários Finais e autoridades, em razão da Aplicação, de uso proibido da API ou de tratamento de dados pessoais feito pelo DESENVOLVEDOR como controlador.

25.2. O FORNECEDOR indenizará o DESENVOLVEDOR pelos valores que este tiver de pagar a terceiro que alegue que a API, usada conforme a Documentação, viola direito de propriedade intelectual.

25.3. A parte que receber a reclamação avisará a outra em até [10] dias úteis, permitirá que ela conduza a defesa e não fará acordo sem consentimento por escrito.

Nota: a indenização cruzada põe cada risco com quem o controla: o desenvolvedor responde pela aplicação, e o fornecedor pela API. O aviso rápido e o controle da defesa evitam acordo caro feito por uma parte e cobrado da outra. Em relação de consumo, a indenização exigida do consumidor não pode colocá-lo em desvantagem exagerada (CDC, art. 51, IV), e o juiz examina a cláusula caso a caso.

Cláusula 26ª. Suspensão

26.1. O FORNECEDOR poderá suspender, no todo ou em parte, o acesso à API sem aviso prévio quando houver:

• ataque, uso abusivo ou tráfego que coloque em risco a plataforma ou outros clientes;
• Chave de API exposta ou uso anormal que indique acesso indevido;
• ordem judicial ou de autoridade competente;
• violação grave da Cláusula 8ª ou da Política de Uso Aceitável.

26.2. Nas demais violações, o FORNECEDOR avisará o DESENVOLVEDOR e dará prazo de [5] dias úteis para correção antes de suspender.

26.3. A suspensão será limitada ao necessário, como uma Chave de API, um endpoint ou o ambiente afetado, e será levantada assim que cessar o motivo. O FORNECEDOR informará o motivo da suspensão, salvo quando a informação prejudicar investigação ou for vedada por lei.

Nota: suspender uma API derruba também os clientes do desenvolvedor. Suspensão sem motivo previsto ou desproporcional pode gerar dever de indenizar. A lista de hipóteses urgentes e o prazo de correção nas demais organizam a moderação, no mesmo espírito da política de uso aceitável para SaaS, que detalha as medidas graduais.

Cláusula 27ª. Vigência e encerramento

27.1. Estes termos vigoram por prazo indeterminado, a partir do aceite. Os planos pagos têm o período de contratação indicado no Anexo I, com renovação automática salvo aviso contrário com [30] dias de antecedência.

27.2. O DESENVOLVEDOR pode encerrar a conta a qualquer tempo pelo painel. Nos planos pagos com fidelidade, aplica-se a multa do Anexo I, proporcional ao período restante.

27.3. O FORNECEDOR pode encerrar a conta:

• sem motivo, com aviso de [90] dias para planos pagos e de [30] dias para o plano gratuito, respeitada a Cláusula 13ª se o encerramento decorrer de descontinuação;
• por violação destes termos não corrigida no prazo da Cláusula 26ª;
• de imediato, em caso de fraude, violação da Cláusula 22ª ou uso da API para atividade ilícita.

Nota: o encerramento sem motivo é permitido em contrato por prazo indeterminado, mediante denúncia notificada (CC, art. 473). Em relação de consumo, a cláusula que dá só ao fornecedor o direito de cancelar é nula (CDC, art. 51, XI); por isso o modelo garante ao desenvolvedor o direito de sair a qualquer tempo. Multa de fidelidade excessiva pode ser reduzida pelo juiz (CC, art. 413).

Cláusula 28ª. Efeitos do término

28.1. Com o término, por qualquer motivo:

• as Chaves de API serão revogadas e a licença da Cláusula 3ª termina;
• o DESENVOLVEDOR deixará de usar as marcas do FORNECEDOR e apagará os Dados da API guardados em cache em até [30] dias;
• os valores vencidos e o uso medido até a data do término continuam devidos;
• o FORNECEDOR manterá os Dados do Desenvolvedor disponíveis para exportação em formato estruturado por [30] dias, salvo término por fraude ou ordem de autoridade.

28.2. Continuam valendo depois do término as cláusulas de propriedade intelectual, proteção de dados, confidencialidade, limitação de responsabilidade, indenização, pagamento e foro.

Nota: a janela de exportação protege o desenvolvedor que precisa migrar, e o prazo para apagar o cache protege o fornecedor contra o uso de dados depois do fim. A lista de cláusulas que sobrevivem evita a tese de que, encerrada a conta, o sigilo e a responsabilidade por dados também acabaram.

Cláusula 29ª. Comunicações

29.1. As comunicações do FORNECEDOR serão feitas pelos e-mails do cadastro, pelo painel da conta ou pelo registro de alterações da Documentação, conforme o tipo de aviso. As do DESENVOLVEDOR, pelos canais do Anexo IV.

29.2. Considera-se recebida a comunicação enviada ao e-mail do cadastro no dia útil seguinte ao envio. O DESENVOLVEDOR é responsável por manter os e-mails atualizados.

Nota: quase todas as proteções do modelo dependem de aviso: alteração dos termos, descontinuação, suspensão, reajuste. Fixar o canal e o momento em que o aviso se considera recebido evita a alegação de que o desenvolvedor nunca soube da mudança.

Cláusula 30ª. Disposições gerais

30.1. O DESENVOLVEDOR não pode ceder estes termos sem autorização por escrito. O FORNECEDOR pode cedê-los a empresa do mesmo grupo ou a quem adquirir a plataforma, com aviso ao DESENVOLVEDOR.

30.2. Não há vínculo societário, de emprego ou de representação entre as partes. A tolerância com um descumprimento não altera estes termos. A nulidade de uma cláusula não afeta as demais.

30.3. Estes termos, com os documentos da Cláusula 1ª, formam o acordo integral sobre o uso da API. Havendo versão em outro idioma, prevalece a versão em português.

Nota: as disposições gerais parecem burocráticas, mas resolvem problemas reais: a venda da empresa fornecedora (cessão), o desenvolvedor que diz ter um acordo verbal (acordo integral) e a tradução que diverge do original (idioma). Entre empresas, a lei permite pactuar regras de interpretação próprias (CC, art. 113, § 2º).

Cláusula 31ª. Aceite eletrônico, assinatura e título executivo

31.1. O aceite por meio do portal, com registro de conta, data, hora, endereço IP e versão aceita, comprova a adesão a estes termos.

31.2. No plano corporativo, o pedido de compra pode ser assinado eletronicamente por qualquer modalidade de assinatura eletrônica prevista em lei. Assinado por duas testemunhas, ou com assinatura eletrônica cuja integridade seja conferida por provedor de assinatura, o pedido de compra é título executivo extrajudicial quanto aos valores nele previstos.

Nota: o aceite por clique prova o contrato, mas dificilmente serve como título executivo. Para cobrar por execução, use o pedido de compra assinado: o documento particular assinado pelo devedor e por duas testemunhas é título executivo (CPC, art. 784, III), e, no meio eletrônico, as testemunhas são dispensadas quando um provedor de assinatura confere a integridade (§ 4º).

Cláusula 32ª. Lei aplicável e foro

32.1. Estes termos são regidos pelas leis do Brasil.

32.2. Se o DESENVOLVEDOR for consumidor, poderá propor ação no foro do seu domicílio. Nas relações entre empresas, fica eleito o foro da comarca de [cidade/UF], sede do FORNECEDOR, [ou / com a opção de] arbitragem na forma prevista no pedido de compra do plano corporativo.

Nota: o consumidor pode propor a ação no próprio domicílio (CDC, art. 101, I), e a arbitragem compulsória é nula em contrato de consumo (CDC, art. 51, VII). Entre empresas, o foro eleito precisa ter pertinência com o domicílio de uma das partes ou com o local da obrigação (CPC, art. 63, § 1º, redação da Lei 14.879/2024), e a ação em juízo aleatório autoriza o juiz a declinar da competência (§ 5º).

[Cidade/UF], versão publicada em [dia] de [mês] de [ano].

[Razão social do FORNECEDOR]

Anexo I. Planos, limites e preços

Período de contratação: [mensal / anual]. Fidelidade: [sem fidelidade / 12 meses, com multa de (percentual) do valor das mensalidades restantes]. Tributos: [incluídos / não incluídos] no preço.

Anexo II. Nível de serviço e suporte

Disponibilidade é a porcentagem de minutos do mês em que a API respondeu às requisições válidas sem erro do servidor, medida pelo FORNECEDOR e publicada no painel de status. O crédito deve ser pedido em até [30] dias do fim do mês.

Anexo III. Política de versões e descontinuação

Versão atual: [v2]. Versões suportadas: [v1, até (data); v2]. Endereço do guia de migração: [link].

Anexo IV. Contatos

• Suporte técnico: [e-mail ou formulário];
• Aviso de vazamento de Chave de API e incidentes de segurança: [e-mail], [telefone para emergências];
• Relato responsável de vulnerabilidades: [endereço];
• Financeiro e contestação de faturas: [e-mail];
• Encarregado pelo tratamento de dados pessoais: [nome], [e-mail];
• Notificações jurídicas: [e-mail] e [endereço].

Nota: os anexos são a parte que o desenvolvedor mais consulta e a que mais muda. Mantê-los separados permite atualizar preço, limite e contato sem reescrever as cláusulas, desde que a mudança siga os avisos das Cláusulas 6ª, 14ª e 15ª. Preencha todos antes de publicar: anexo com colchetes abertos é cláusula sem conteúdo.

TERMOS DE USO DA API [NOME DA API] (VERSÃO SIMPLES)

FORNECEDOR: [razão social], CNPJ nº [número], com sede na [endereço completo com CEP], e-mail [e-mail], encarregado de dados [nome], e-mail [e-mail].

DESENVOLVEDOR: a pessoa física maior de 18 anos ou a pessoa jurídica que cria conta no portal [endereço] e aceita estes termos. Versão [número], vigente desde [data].

Ao criar a conta ou usar a API, o DESENVOLVEDOR aceita estes termos e a Política de Privacidade em [link].

Cláusula 1ª. Objeto

1.1. O FORNECEDOR concede licença limitada, não exclusiva, intransferível e sem direito de sublicenciar para que o DESENVOLVEDOR integre sua aplicação à API, conforme a documentação publicada.

1.2. Não fazem parte destes termos o desenvolvimento da aplicação do DESENVOLVEDOR, consultoria de integração e acesso ao código-fonte da API.

Cláusula 2ª. Chaves de API

2.1. As chaves são confidenciais. O DESENVOLVEDOR não as colocará em código público ou em aplicativo distribuído ao público, e avisará o FORNECEDOR em até [24] horas se houver vazamento.

2.2. O uso feito com a chave é cobrado do DESENVOLVEDOR até o aviso de vazamento. Depois do aviso, o FORNECEDOR revogará a chave e não cobrará o uso posterior.

Cláusula 3ª. Limites e cotas

3.1. Os limites de requisição e as cotas de cada plano estão em [link para a página de planos]. Acima do limite, a API recusará requisições até a liberação indicada na resposta.

3.2. É proibido usar várias contas ou chaves para ultrapassar os limites. A redução de limite de plano pago só vale na renovação seguinte, com aviso de [30] dias.

Cláusula 4ª. Uso proibido

4.1. O DESENVOLVEDOR não pode:

• extrair dados por scraping fora da API;
• revender ou repassar o acesso à API a terceiros;
• fazer engenharia reversa da API, salvo quando a lei permitir;
• usar os dados da API para criar produto que substitua o [nome do serviço] ou para treinar modelos de IA sem autorização;
• fazer testes de invasão ou de carga sem autorização por escrito;
• usar a API para atividade ilícita.

Cláusula 5ª. Preço e pagamento

5.1. Os preços estão na página de planos. A cobrança é [mensal], por [cartão / boleto / Pix], com nota fiscal. O uso é medido pelos registros do FORNECEDOR, disponíveis no painel, e pode ser contestado em até [30] dias.

5.2. O atraso gera multa de 2%, juros de [1% ao mês / taxa legal do art. 406 do Código Civil] e correção pelo IPCA. Depois de aviso com prazo de [5] dias úteis, o FORNECEDOR pode suspender as chaves de produção até o pagamento. Os preços são reajustados anualmente pelo IPCA.

Cláusula 6ª. Versões e descontinuação

6.1. Mudanças que exijam alterar o código da aplicação só serão feitas em nova versão, e a versão anterior funcionará por pelo menos [12] meses depois do aviso.

6.2. A descontinuação da API inteira terá aviso de [12] meses. Se o DESENVOLVEDOR tiver plano pago, poderá encerrá-lo sem multa e receberá o valor proporcional já pago.

Cláusula 7ª. Propriedade intelectual e dados

7.1. A API, a documentação e as marcas são do FORNECEDOR. A aplicação e os dados enviados pelo DESENVOLVEDOR são dele.

7.2. As partes cumprirão a Lei 13.709/2018 (LGPD). O DESENVOLVEDOR é controlador dos dados pessoais que tratar na aplicação e não enviará dados sensíveis à API sem autorização. O FORNECEDOR avisará o DESENVOLVEDOR em até [48] horas sobre incidente de segurança que afete os dados dele.

Cláusula 8ª. Disponibilidade e responsabilidade

8.1. O FORNECEDOR busca manter a API disponível, mas não garante funcionamento ininterrupto no plano gratuito.

8.2. Entre empresas, a responsabilidade de cada parte fica limitada ao valor pago nos [12] meses anteriores ao fato, salvo dolo, culpa grave ou violação de dados pessoais. Se o DESENVOLVEDOR for consumidor, valem as regras do Código de Defesa do Consumidor.

Cláusula 9ª. Alterações, suspensão e encerramento

9.1. Alterações destes termos serão avisadas por e-mail com [30] dias de antecedência. Quem não concordar pode encerrar a conta sem multa antes da vigência.

9.2. O FORNECEDOR pode suspender o acesso sem aviso em caso de ataque, chave exposta, ordem de autoridade ou violação grave. Nos demais casos, avisará e dará [5] dias úteis para correção.

9.3. O DESENVOLVEDOR pode encerrar a conta a qualquer tempo. O FORNECEDOR pode encerrá-la com aviso de [30] dias, ou de imediato em caso de fraude ou uso ilícito. Com o término, as chaves são revogadas, o DESENVOLVEDOR apaga os dados da API guardados em até [30] dias e pode exportar seus dados no mesmo prazo.

Cláusula 10ª. Disposições gerais e foro

10.1. O aceite eletrônico, com registro de data, hora, IP e versão, comprova a adesão. Pedido de compra assinado eletronicamente com provedor que confira a integridade, ou por duas testemunhas, é título executivo extrajudicial (CPC, art. 784, III e § 4º).

10.2. Fica eleito o foro da comarca de [cidade/UF] para as relações entre empresas. O consumidor pode propor ação no foro do seu domicílio.

[Cidade/UF], versão publicada em [dia] de [mês] de [ano].

[Razão social do FORNECEDOR]