Dados, retenção e privacidade

Esta página existe para a conversa que acontece antes da integração: a do jurídico, a do encarregado de dados, a de quem precisa responder “o que exatamente sai da nossa casa e por quanto tempo fica na de vocês?”.

Ela é honesta em duas direções. Diz o que o serviço faz, com número; e diz claramente o que não é respondido aqui, para você não confundir silêncio com promessa.

---

1. Que dado pessoal a API recebe

O PushMesh não pede documento, nome, telefone nem e-mail de usuário final. O que ele recebe é o mínimo para entregar uma notificação — e uma parte disso é dado que você escolhe mandar.

A decisão de privacidade mais importante desta API é sua, não nossa: o que você põe em external_user_id e em tags. Um identificador opaco de conta mantém a base pseudonimizada. Um e-mail em texto claro ou um número de documento faz a sua base de push virar uma base de dados pessoais — com todas as obrigações que isso traz. Prefira o identificador opaco que só o seu sistema sabe resolver.

Anote também: o arquivo de exportação carrega external_user_id, e o que o protege é a URL ser impossível de adivinhar. URL de export em ticket, em chat ou em log é vazamento. Ela vale por 72 horas.

---

2. Quanto tempo cada camada guarda

Duas consequências que valem entender antes de montar relatório:

• Consulta detalhada de entrega tem prazo; número agregado não. Se o seu relatório precisa saber quais aparelhos receberam uma campanha de dois meses atrás, essa granularidade não está mais na consulta rápida. Se ele precisa saber quantos receberam, está — e sempre estará.
• A janela de 90 dias do recibo não é generosidade. Ela cobre o pior caso legítimo: um agendamento de até 28 dias somado a um prazo de entrega de até 28 dias, mais folga, porque o clique pode vir de uma notificação parada na bandeja por semanas. Um recibo que chega depois de a linha detalhada já ter esfriado responde {"ok": true, "tardio": true} — ele conta, por outro caminho.

---

3. Como atender um pedido de exclusão

Não existe rota pública que apague um aparelho, e a ausência é deliberada: as rotas de aparelho são públicas por desenho, e uma rota pública capaz de apagar seria uma rota pública capaz de esvaziar a sua base.

O que existe, e é o caminho oficial:

Receita prática para um pedido de titular, quando você guarda o external_user_id do seu lado:

1. Localize os aparelhos daquela pessoa — o external_user_id é o seu índice, e o arquivo de exportação traz a coluna.
2. Faça o logout explícito (external_user_id: null) para cortar o vínculo na hora, mesmo antes da exclusão.
3. Apague os aparelhos pelo painel. O rastro de entrega deles vai junto.

Duas honestidades:

• Apagar não é banir. Um aparelho vivo que você apagou volta a se registrar sozinho no próximo uso do aplicativo. Para não voltar a falar com alguém, a ferramenta é o vínculo (logout) ou a sua própria regra de público.
• A exclusão de um aplicativo tem um limite conhecido, e ele está dito aqui em vez de escondido: as imagens que você subiu para usar em push ficam no armazenamento de objetos depois da exclusão. Elas deixam de ser alcançáveis (a única referência a elas morre junto com as mensagens), mas o arquivo em si permanece. Fechar isso é uma pendência registrada.

---

4. O que o serviço não guarda

• A sua chave de API. No banco fica apenas um resumo criptográfico dela. Ninguém — nem o suporte — consegue exibi-la de novo.
• A chave que assina os recibos, a credencial do Firebase e o .p8 do APNs ficam cifrados e nunca saem do servidor depois de gravados.
• A credencial apresentada numa tentativa recusada. O registro de auditoria guarda, no máximo, o identificador público da chave — nunca a chave tentada.
• Dado pessoal nos registros de operação. Os registros do serviço trabalham com identificadores e números; é regra do projeto que dado pessoal não entra neles.

---

5. O que esta página não responde

Estes pontos não são decididos pela API, e inventar uma resposta aqui seria pior do que não ter nenhuma. Peça-os por escrito antes de fechar contrato:

• Onde os dados ficam fisicamente (região e país de armazenamento);
• Quem são os subprocessadores — além dos óbvios Google (FCM) e Apple (APNs), que são inerentes ao produto: sem eles não existe push;
• Compromisso de disponibilidade (SLA) e página de estado;
• A política de privacidade completa e os termos definitivos.

O que já está publicado hoje está em Privacidade e Termos de uso, e essas páginas dizem, com todas as letras, que a versão completa vem antes da abertura comercial. Para o documento que o seu jurídico precisa agora, escreva para contato@pushmesh.io.

Duas coisas que já são compromisso público e valem repetir aqui: não vendemos dados, não criamos perfis publicitários e não compartilhamos a sua base com terceiros; e os recibos de entrega existem para prestar conta a você, o dono da base.

---

Veja também