The controlling text is available in Portuguese. An English translation is not yet available.
1. Objeto e elegibilidade
1.1. Estes Termos regulam o acesso programático ao Serviço por API, webhook, OAuth, Model Context Protocol, chave de API, ferramenta, recurso, SDK, extensão ou aplicação desenvolvida pelo Cliente ou por terceiro autorizado.
1.2. O acesso destina-se exclusivamente a pessoa jurídica contratante e a desenvolvedores sob sua responsabilidade, dentro do Pedido, documentação técnica vigente, escopos concedidos e leis aplicáveis.
1.3. Nenhum endpoint, exemplo, preview, schema, catálogo ou código demonstra disponibilidade geral, estabilidade, gratuidade, compatibilidade retroativa ou autorização para produção sem habilitação e credencial válidas.
1.4. Estes Termos complementam os Termos B2B, DPA, Uso Aceitável, Termos de Integrações, Termos de IA, Política de Segurança e Anexo Territorial, prevalecendo a regra específica ou proteção superior.
1.5. Aplicação destinada a múltiplos clientes, marketplace, revenda, redistribuição ou acesso de terceiro poderá exigir contrato, revisão de segurança, marca, suporte, privacidade e aprovação separados.
2. Definições técnicas e jurídicas
2.1. Aplicação significa software que acessa a Plataforma; Desenvolvedor significa pessoa autorizada pelo Cliente; Credencial inclui chave, segredo, token, certificado, código, sessão ou material capaz de autenticar ou autorizar.
2.2. Escopo é permissão nominal solicitada; Ferramenta MCP é operação disponibilizada a cliente compatível; Recurso MCP é dado consultável; Invocação é pedido executado ou tentado contra ferramenta, API ou webhook.
2.3. Operação de Leitura consulta dado; Operação de Escrita cria, altera, envia, move, associa ou exclui; Operação Sensível produz efeito externo, financeiro, comunicacional, pessoal, irreversível ou de risco elevado.
2.4. Usuário Final é pessoa que autoriza ou utiliza a Aplicação; Organização é tenant do Cliente; Dado da Aplicação inclui inputs, outputs, tokens, payloads, logs e derivados tratados na integração.
2.5. Documentação Técnica descreve contrato de interface, mas não modifica preço, responsabilidade, proteção de dados, SLA, território ou direito sem incorporação válida ao instrumento aplicável.
3. Cadastro autoridade e ambiente
3.1. O Desenvolvedor deverá atuar em nome de Organização identificada, manter contato válido e possuir poderes para solicitar acesso, registrar Aplicação, aceitar termos e configurar operações sobre dados e usuários alcançados.
3.2. Ambientes de desenvolvimento, teste, sandbox e produção serão separados quando disponibilizados; dado real não deverá ser copiado para teste sem necessidade, base, proteção, retenção e autorização compatíveis.
3.3. O Cliente responderá por seus Desenvolvedores, prestadores e Aplicações como por ato próprio no âmbito contratado, preservado o direito de regresso e a responsabilidade direta de cada infrator conforme lei.
3.4. Identidade, Organização ativa e permissão deverão ser verificadas em cada operação material; parâmetro enviado pelo cliente não substituirá contexto autenticado nem autorizará acesso cross-tenant.
3.5. Aivyro poderá exigir avaliação técnica, prova de domínio, política de privacidade, contato de segurança, descrição de finalidade, teste, limitação de usuários ou revisão periódica antes ou depois da habilitação.
4. OAuth e consentimento
4.1. Fluxo OAuth deverá usar cliente registrado, redirect URI validada, state, PKCE quando aplicável, escopos explícitos e troca segura de código, sendo vedado interceptar credencial ou induzir usuário a autorizar organização diversa.
4.2. A tela de consentimento deverá identificar a Aplicação, Organização, conta e escopos solicitados em linguagem suficiente para decisão, sem ocultar operação de escrita sob descrição genérica de conexão.
4.3. O Cliente solicitará subconjunto de menor privilégio; escopo suportado não integra automaticamente o conjunto padrão e inclusão futura no catálogo não concede permissão a token anterior.
4.4. Redirect URI não poderá conter credenciais embutidas, fragmento malicioso, domínio enganoso ou destino não controlado; loopback e custom scheme somente serão usados nos casos tecnicamente autorizados e com proteção contra sequestro.
4.5. Negação, revogação, expiração, troca de Organização ou falha de autorização deverá interromper o fluxo correspondente sem contornar a decisão por chave alternativa ou token pertencente a outro usuário.
5. Chaves tokens e sessões
5.1. Chave de API poderá ser oferecida para cliente de compatibilidade, mas OAuth será preferido quando suportado; a chave será exibida segundo o fluxo previsto e deverá ser armazenada como segredo pelo Cliente.
5.2. Credencial será individualizada por Organização, proprietário, escopos, criação, expiração e estado quando tecnicamente aplicável, sendo proibido compartilhar chave pessoal entre equipe, cliente, ambiente ou produto.
5.3. Token não será enviado a host MCP como passthrough fora do desenho autorizado, incluído em URL, repositório, log público, prompt, ticket ou analytics, nem conservado após revogação além de evidência mínima segura.
5.4. O Cliente revogará imediatamente credencial exposta, não utilizada, vinculada a usuário desligado ou finalidade encerrada; apagar a string de uma interface ou mensagem não invalida o segredo persistente.
5.5. Aivyro poderá encerrar sessão, rotacionar chave ou exigir reautorização por risco, mudança de escopo, incidente, inatividade, término ou política, informando impacto conforme urgência e contrato.
6. Escopos permissões e menor privilégio
6.1. Escopos de CRM, conversas, mensagens, reuniões, automações, forecasting, analytics e outros domínios permanecerão separados por objeto e operação, e o nome do domínio não autorizará tudo que nele exista.
6.2. Escopo de leitura não permite escrita; escopo de escrita não permite ação administrativa, acesso de outra Organização ou finalidade incompatível; autorização técnica é teto, não base universal de tratamento.
6.3. Ferramenta sensível poderá exigir permissão adicional, cap, confirmação humana, política organizacional ou bloqueio, mesmo quando a credencial possua escopo nominalmente compatível.
6.4. Administrador poderá governar acesso, limites, sessões, histórico e revogações conforme permissões; usuário não poderá elevar próprio privilégio, escolher tenant alheio ou contornar separação por chamada direta.
6.5. A Aplicação deverá reavaliar necessidade de escopos e remover permissões não utilizadas; mudança material de finalidade ou funcionalidade exigirá nova análise e, quando aplicável, novo consentimento.
7. MCP agentes e ferramentas
7.1. MCP constitui fronteira de ferramentas e recursos, não agente autônomo nem autorização para executar qualquer plano; cliente externo, modelo ou orquestrador continuará responsável por seleção, contexto e confirmação que controla.
7.2. O catálogo deverá informar nome, descrição, schema, escopos e risco das ferramentas disponíveis, mas preview do registry não comprova chamada bem-sucedida, dado existente, permissão efetiva ou disponibilidade contínua.
7.3. Operação de escrita ou efeito externo deverá receber parâmetros válidos, autorização tenant-scoped e confirmação proporcional; texto gerado por modelo não será tratado como instrução confiável sem validação de código e contexto.
7.4. Cliente externo deverá exibir ao usuário ações materiais antes ou depois da execução conforme risco, preservar oportunidade de revisão e não representar proposta do modelo como fato consumado.
7.5. Resultado de ferramenta poderá ser parcial, desatualizado, negado ou abstido; a Aplicação deverá respeitar estado, erro, confiança, fonte e próximo passo, sem completar informação ausente por inferência não identificada.
8. APIs contratos e versionamento
8.1. A Aplicação obedecerá método, rota, schema, tipo, limite, autenticação, idempotência e semântica documentados, não dependendo de campo privado, ordem incidental, mensagem interna ou comportamento não contratual.
8.2. Resposta de sucesso de transporte não garante que operação assíncrona foi concluída; o Desenvolvedor deverá observar status, recurso autoritativo, evento ou confirmação exigida pela API.
8.3. Versão poderá evoluir com adição compatível, correção de segurança ou descontinuação; breaking change planejada seguirá política e prazo comunicados quando contratualmente devidos.
8.4. Campo experimental, opcional ou desconhecido deverá ser tratado defensivamente, e a Aplicação não deverá falhar de modo inseguro, apagar dado ou executar ação ampliada por variação legítima do schema.
8.5. Erro deverá ser processado conforme classe, retryability e efeito conhecido, evitando loop, tempestade, duplicidade ou exposição de dado; mensagem de erro não substitui contrato nem deve ser exibida a público sem sanitização.
9. Webhooks e eventos
9.1. Endpoint receptor deverá utilizar HTTPS quando aplicável, validar assinatura, timestamp e origem, responder dentro da janela, processar idempotentemente e proteger segredo e payload.
9.2. Eventos poderão ser entregues mais de uma vez, fora de ordem, com atraso ou após alteração concorrente; a Aplicação confirmará estado autoritativo antes de decisão irreversível quando necessário.
9.3. Retry terá política e limite documentados quando contratado, sem garantia de entrega exatamente uma vez; falha persistente poderá pausar assinatura ou encaminhar evento a dead letter.
9.4. Payload deverá conter somente o necessário ao evento e não poderá ser retido indefinidamente; o Desenvolvedor deverá definir descarte, replay, acesso e investigação compatíveis com sensibilidade.
9.5. Segredo comprometido, endpoint desativado ou consumo anômalo deverá ser comunicado e remediado, podendo a Aivyro suspender entrega para impedir vazamento, abuso ou degradação.
10. Limites quotas e custos
10.1. Requisições, tokens, sessões, ferramentas, dados, armazenamento e tempo poderão estar sujeitos a limites por Organização, usuário, Aplicação, plano ou período, conforme Pedido e documentação vigente.
10.2. Cap diário, rate limit e throttling poderão proteger disponibilidade, segurança e custo; tentativa de distribuir chamadas, alternar credenciais ou multiplicar tenants para contornar limite é proibida.
10.3. Resposta de limite não autoriza retry agressivo; a Aplicação observará backoff, janela e instrução, preservando idempotência e evitando impacto a outros clientes.
10.4. Uso mensurado somente será cobrado conforme unidade, preço e consequência aceitos, distinguindo teste, falha, retry e duplicidade quando material; disponibilidade de métrica não cria tarifa não contratada.
10.5. Aivyro poderá ajustar limite não contratado por risco ou capacidade, mas redução material de direito pago seguirá Pedido, SLA e comunicação aplicáveis.
11. Dados privacidade e instruções
11.1. A Aplicação tratará apenas dados necessários à finalidade informada, manterá aviso e base aplicáveis e não combinará Dado do Cliente com fonte externa para publicidade, perfil sensível ou venda sem autorização válida.
11.2. Aivyro tratará chamadas, payloads e resultados conforme DPA quando atuar por instrução; logs de segurança, cobrança e prevenção de abuso poderão ter finalidade própria limitada e transparência correspondente.
11.3. O Desenvolvedor implementará direitos, correção, exclusão, retenção e exportação sobre cópias sob seu controle e cooperará para propagar solicitação entre sistemas relevantes.
11.4. Transferência internacional, subprocessador, modelo, armazenamento e região dependerão do fluxo real, não do local do Desenvolvedor ou do domínio da Aplicação, e deverão observar mecanismo contratual e territorial aplicável.
11.5. Dados sensíveis, gravações, voiceprints, saúde, menores e conteúdo regulado somente serão acessados por escopo, instrumento, finalidade e controles específicos; acesso técnico genérico não constitui autorização.
12. Segurança da Aplicação
12.1. O Desenvolvedor manterá ciclo seguro de desenvolvimento, dependências atualizadas, revisão de acesso, proteção de segredo, validação de entrada, autorização por objeto, logging e resposta a incidentes proporcionais ao risco.
12.2. É proibido armazenar token em código cliente público, commit, imagem, prompt, log ou analytics; material exposto deverá ser revogado, rotacionado e investigado, não apenas mascarado posteriormente.
12.3. A Aplicação deverá isolar organizações, impedir referência direta insegura, validar permissão no servidor e não confiar em organização, usuário, papel ou objeto informados exclusivamente pelo navegador.
12.4. Dados em trânsito e repouso serão protegidos por mecanismos adequados ao contexto, sem afirmar algoritmo, certificação ou cobertura não comprovados; alternativa a criptografia exigirá justificativa e controle compensatório.
12.5. Vulnerabilidade será reportada pelo canal autorizado com detalhe suficiente e sem exploração destrutiva, extorsão, acesso a terceiro ou divulgação prematura; boa-fé não autoriza violar lei ou termo.
13. Segurança da plataforma e responsabilidade compartilhada
13.1. Aivyro manterá controles razoáveis sobre autenticação, autorização, segregação, gestão de credenciais, observabilidade, vulnerabilidades e incidentes em sua camada, conforme Política de Segurança e DPA.
13.2. Aivyro não responderá por código, host, dispositivo, prompt, modelo, segredo ou usuário sob controle da Aplicação, mas continuará responsável por vulnerabilidade ou tratamento próprio que contribua para o dano.
13.3. Cliente não responderá por falha exclusiva da Plataforma nem será obrigado a auditar componente invisível sem evidência adequada; cada parte cooperará na investigação sem deslocar artificialmente seu domínio.
13.4. Controle descrito em documentação é compromisso somente na versão e escopo incorporados; claim comercial, certificação ou arquitetura futura não deverá ser usada como prova de implementação atual.
13.5. Mudança que reduza materialmente proteção contratada exigirá avaliação, mitigação e comunicação conforme risco, sem impedir melhoria ou substituição equivalente.
14. Monitoramento auditoria e evidência
14.1. Aivyro poderá registrar invocação, credencial, usuário, Organização, ferramenta, escopo, horário, resultado, erro, consumo e revogação para segurança, suporte, cobrança, auditoria e melhoria operacional legítima.
14.2. Logs serão minimizados, protegidos e retidos conforme finalidade, não devendo reproduzir segredo ou conteúdo integral quando metadado suficiente atender à investigação.
14.3. Administrador autorizado poderá consultar histórico e uso da Organização; acesso administrativo não permite monitoramento clandestino de usuário fora da finalidade, lei, política interna e transparência aplicáveis.
14.4. Indício de abuso, comprometimento, volume anômalo ou violação poderá resultar em limitação, investigação ou pedido de informação, preservados confidencialidade, proporcionalidade e defesa compatíveis com a urgência.
14.5. Auditoria contratual seguirá escopo, frequência, segurança, confidencialidade e não interferência definidos no DPA ou Pedido, priorizando evidência independente antes de acesso intrusivo.
15. Usos proibidos
15.1. É proibido acessar tenant, objeto, ferramenta, dado ou credencial sem autorização; fazer scraping não permitido; contornar limite; testar destrutivamente; transmitir malware; interferir ou tentar extrair segredo, código ou modelo.
15.2. A Plataforma não será usada para spam, fraude, vigilância ilícita, discriminação, impersonação, deepfake malicioso, decisão proibida, comunicação sem consentimento exigido ou tratamento incompatível de dado sensível.
15.3. É proibido apresentar Aplicação como produto oficial, afirmar parceria, certificação ou revisão inexistente, ocultar a identidade do operador ou induzir Usuário Final a conceder escopo por descrição enganosa.
15.4. Dado obtido por API não poderá ser vendido, enriquecido ou redistribuído fora da finalidade, nem usado para treinar modelo compartilhado sem autorização específica e instrumentos aplicáveis.
15.5. Violação poderá resultar em revogação, bloqueio, preservação de evidência, comunicação ao Cliente, provedor ou autoridade e demais remédios, conforme gravidade, risco e procedimento dos Termos B2B.
16. Aplicações para terceiros e marketplace
16.1. Aplicação que atenda múltiplas Organizações deverá separar tenants, credenciais, dados, logs e administradores e não poderá reutilizar consentimento, token ou configuração de um cliente em outro.
16.2. O Desenvolvedor fornecerá termos, privacidade, suporte, contato de segurança, finalidade e instruções próprias aos Usuários Finais e não afirmará que a Aivyro controla ou responde por seu serviço.
16.3. Distribuição pública poderá exigir revisão de segurança, experiência, marca, escopos, cobrança e suporte, sem que aprovação inicial garanta permanência ou endosso.
16.4. Aivyro poderá remover listagem ou bloquear nova instalação por risco, violação, abandono, reclamação, mudança técnica ou legal, preservando procedimento e dados conforme contrato e urgência.
16.5. Desenvolvedor será responsável por suporte de sua Aplicação e por comunicação de mudança, incidente e término aos clientes afetados, sem atribuir à Aivyro obrigação não assumida.
17. Propriedade licença e feedback
17.1. Aivyro conserva direitos sobre Plataforma, APIs, documentação, schemas, marcas e tecnologia; Cliente conserva direitos sobre sua Aplicação e Dados, ressalvadas licenças limitadas necessárias à interoperabilidade.
17.2. A licença de acesso é limitada, não exclusiva, revogável e intransferível fora do Pedido, não autorizando cópia do Serviço, engenharia reversa proibida por lei, criação de substituto por extração ou uso de marca sem permissão.
17.3. Interface, formato ou ideia não transfere segredo nem direito sobre implementação; cada parte preservará código, documentação e informação confidencial recebidos.
17.4. Feedback poderá ser utilizado pela Aivyro sem obrigação de incorporar ou remunerar, desde que não revele Dado do Cliente, segredo ou propriedade do Desenvolvedor de modo não autorizado.
17.5. Reclamação de infração será tratada conforme Termos B2B, podendo exigir remoção, substituição, licença, suspensão ou defesa na extensão atribuível a cada parte.
18. Mudança descontinuação e suporte
18.1. Aivyro poderá adicionar capacidade compatível, corrigir falha e alterar implementação preservando contrato; mudança material incompatível seguirá versionamento, aviso e descontinuação aplicáveis.
18.2. Vulnerabilidade, ordem, abuso ou mudança de provedor poderá exigir alteração imediata, revogação ou bloqueio sem prazo ordinário, com informação posterior quando segura.
18.3. Suporte, ambiente, prazo de resposta, migração e manutenção dependerão do Pedido ou política aplicável; acesso programático não cria SLA próprio.
18.4. Versão beta, preview ou experimental poderá mudar ou ser retirada, possuir limites e retenção diferentes e não deverá sustentar processo crítico sem contingência do Cliente.
18.5. Aplicação deverá monitorar avisos técnicos e manter contato atualizado; omissão não transfere à Aivyro consequência que poderia ser razoavelmente evitada, preservada a responsabilidade por aviso contratualmente devido.
19. Suspensão término e destinação
19.1. Cliente poderá revogar credencial e encerrar uso, permanecendo responsável por operações já executadas, cobrança devida, cópias e dados sob seu controle e comunicação a Usuários Finais.
19.2. Aivyro poderá suspender por violação, risco, comprometimento, excesso, não pagamento, ordem ou término, limitando a medida ao necessário quando a natureza permitir.
19.3. Após término, novas chamadas serão recusadas e sessões ou tokens serão encerrados conforme capacidade técnica; logs mínimos e dados persistentes seguirão retenção, DPA e obrigação legal.
19.4. O Desenvolvedor removerá credenciais, cessará uso de marca e API, eliminará ou devolverá dados quando devido e manterá apenas cópia legitimamente necessária e protegida.
19.5. Confidencialidade, propriedade, segurança, proteção de dados, pagamento, responsabilidade, auditoria e destinação sobreviverão enquanto seus fatos ou finalidades persistirem.
20. Responsabilidade território e vigência
20.1. Cada parte responderá pelo componente, decisão, dado e pessoa sob seu controle; integração técnica não transforma a Aivyro em desenvolvedora da Aplicação nem o Cliente em operador da infraestrutura Aivyro.
20.2. Indenização e limitação seguirão Termos B2B e lei, sem afastar dolo, fraude, violação inderrogável ou responsabilidade que não possa ser validamente excluída.
20.3. País, estado, província, setor, dado, canal e operação poderão exigir restrição, contrato ou bloqueio adicional, ainda que a API esteja acessível pela internet.
20.4. Evidência de aceite deverá identificar versão, Organização, usuário, Pedido, Aplicação, escopos e data, sem que uso isolado de endpoint legitime minuta não vigente.
20.5. Estes Termos vigoram na data indicada e tornam-se obrigatórios para a Aplicação quando incorporados ao Pedido, ao cadastro de desenvolvedor ou a outro aceite válido. Documentação técnica não amplia escopo, garantia ou autorização além destes Termos e das credenciais concedidas.