1. Escopo
Esta política trata exclusivamente dos dados que trafegam pela API de parceiro Googa — as chamadas de servidor-a-servidor entre o sistema de um parceiro integrador (ex.: o backend da Algar) e as APIs Platform, NovelAI, HistorinhAI e NovelAudio, incluindo entitlements, status de assinante, uso para billing, webhooks e SSO. Ela não é a política de privacidade do aplicativo para o usuário final — cada produto Googa (NovelAI, HistorinhAI, NovelAudio) tem sua própria política de privacidade voltada ao leitor/ assinante final, publicada dentro do respectivo app, que cobre o tratamento completo de dados dentro do produto (cadastro, uso do app, preferências, etc.). Esta política de API complementa aquelas políticas no ponto específico em que um dado cruza a fronteira entre o sistema do parceiro e a Googa — ela não as substitui nem reduz o alcance delas.2. Papéis (controlador e operador)
O papel de cada parte varia conforme o fluxo de dado, e é importante não tratar “Algar” e “Googa” como um único papel fixo:
Em resumo: para o dado do assinante que entra e sai pela API de parceiro, a Algar é controladora
da relação com o assinante final, e a Googa é operadora do tratamento necessário para entregar o
conteúdo/serviço contratado — a Googa trata esse dado nos limites definidos pelo Contrato de
Parceria e por instrução do Parceiro, e não para finalidade própria alheia a essa entrega. Este
mapeamento segue os mesmos princípios definidos em Privacidade & LGPD.
3. Dados tratados via API
A API de parceiro é desenhada para trafegar o mínimo necessário para operar entitlement, billing e SSO — nunca dado de contato ou dado de leitura individualmente identificável fora do estritamente necessário. Do Parceiro para a Googa (ex.:POST /entitlements, parâmetros de consulta de
GET /billing-usage):
Da Googa para o Parceiro (ex.: resposta de
GET /subscriber-status/{id}, webhooks
subscriber.updated/subscription.canceled, resposta de GET /billing-usage):
- Os mesmos campos acima, refletidos de volta (
subscriber_id,product,plan,status,updated_at); - Dados agregados de billing e uso — contagem de exemplares/assinantes ativos por produto
(
active_count) — nunca um relatório de leitura individualmente identificável de um assinante específico.
4. Dados de crianças (HistorinhAI)
Reforçando o que já vale para toda a plataforma: nenhum dado identificável de criança trafega pela API de parceiro. Osubscriber_id do HistorinhAI identifica a conta do responsável
(assinante), não a criança — perfis infantis, idade, interesses, desafios do mês e o relatório de
desenvolvimento mensal são geridos inteiramente dentro do app, sob controle parental, e não são
campos expostos por nenhum endpoint desta API. Ver Proteção de dados de menores —
ECA para o tratamento completo.
5. Retenção dos dados de integração
Logs de chamadas de API (requisição, resposta, timestamps, credencial usada — não o corpo de dados de negócio além dos campos da seção 3) são retidos por 12 meses, prazo dimensionado para cobrir auditoria de billing (reconciliação de Nota de Débito, contestação de cobrança) e investigação de incidentes de segurança dentro de uma janela razoável. Após esse prazo, os logs são anonimizados ou agregados (ex.: métricas de volume por parceiro/período) e os registros individuais são descartados. Eventos de webhook não são retidos além do necessário para registrar o resultado da entrega — não existe fila própria de reenvio (a entrega é feita em uma única tentativa por disparo; ver Platform API — Eventos).6. Segurança em trânsito e repouso
Os controles técnicos de criptografia em trânsito (TLS 1.3), em repouso (AES-256, com chaves geridas pelo KMS do provedor de nuvem subjacente — a Googa não opera CMK/BYOK própria), segregação de ambientes e princípio de menor privilégio aplicáveis a toda a plataforma — incluindo o tráfego desta API — estão descritos em Segurança da informação — visão geral.7. Direitos do titular no contexto da API
Um assinante final que queira exercer direitos previstos na LGPD (confirmação de tratamento, acesso, correção, exclusão, portabilidade, entre outros) em relação a dados que trafegaram por uma integração de parceiro deve, como regra, acionar o canal do Parceiro — é o Parceiro que mantém a relação direta e o dever de resposta ao titular, na condição de controlador dessa relação (ver Papéis). O fluxo típico é:- O assinante solicita o exercício do direito diretamente ao Parceiro (ex.: canal de atendimento Algar / Minha Algar).
- O Parceiro, de posse do
subscriber_id, repassa a solicitação à Googa — via a própria API (quando o direito puder ser atendido por uma chamada, ex.: suspensão de entitlement) ou via o canal de suporte a parceiros (para solicitações que exigem ação manual, como exclusão de dados de leitura associados a umsubscriber_id). - A Googa atende a solicitação nos limites do que efetivamente processa como operadora — dados sob controle exclusivo do Parceiro (cadastro, contato, fatura) não são detidos pela Googa e não podem ser atendidos por ela.
8. Sub-processadores
A Googa utiliza os seguintes sub-processadores no tratamento de dados relacionados à integração de parceiro:- Supabase — infraestrutura de dados (banco de dados Postgres, autenticação e funções de borda) de cada produto. Ver Modelo de autenticação sobre Supabase para o desenho de isolamento entre produtos e entre parceiros.
- Provedor(es) de LLM (modelo de linguagem) de terceiros, contratado(s) para geração e adaptação assistida de conteúdo editorial (texto e roteiro de narração). É importante ser preciso aqui: esse processamento tem como entrada o texto da obra e metadados editoriais (gênero, arco narrativo, faixa etária de destino) — não processa dados pessoais do leitor/assinante. Os sinais de personalização (histórico de leitura, preferências) usados para selecionar qual obra recomendar são tratados nos sistemas de domínio da Googa, e não são enviados ao provedor de LLM como parte da geração de conteúdo.