Cartazista.online · JC Marketing Digital · atualizado 21 ago 2026
Publicar o app OAuth, e migrar o DNS para a Cloudflare sem derrubar o SaaS, o site de tráfego pago ou o e-mail transacional.
Sua tela está na página certa, só rolada para baixo. O que você está vendo é a lista de usuários de teste; role para cima na mesma página "Público-alvo" — acima do texto "Enquanto o status de publicação mostrar a opção Testando" existe um bloco Status de publicação: Testando com o botão PUBLICAR APP.
O token que já temos não vira de longa duração sozinho
A expiração de 7 dias é uma propriedade do token emitido, não do app. O refresh token no .dev.vars foi emitido enquanto o app estava em Testes — publicar o app não o conserta retroativamente. Depois de publicar, é obrigatório gerar o token de novo, e aí sim ele nasce de longa duração.
Eu rodo o comando assim que você confirmar que publicou. O fluxo é o mesmo de ontem, e agora sem o 403 — com o app publicado, qualquer conta autoriza, e a lista de usuários de teste deixa de importar.
Clique em Publicar app e veja o que o Google pede. Há dois desfechos possíveis, e saber qual é vale mais que qualquer planejamento:
cartazista.online. Sem drama: voltamos a esse passo depois da migração.Me diga qual dos dois aconteceu. Se aparecer uma tela pedindo campos, manda o print que eu digo o que preencher em cada um.
O export correto mudou o quadro. Pelo DNS público eu tinha encontrado dez registros; a zona real tem trinta e um, e três deles são delegações NS para a Lovable Cloud — o tipo de registro que o scan automático da Cloudflare mais erra e que, se perdido, derruba e-mail transacional sem dar nenhum sinal no site.
| Tipo | Nome | Valor | O que é |
|---|---|---|---|
| NS | suporte | ns3.lovable.cloud · ns4.lovable.cloud | delegação viva — Mailgun |
| NS | notify.mail | ns5.lovable.cloud · ns6.lovable.cloud | delegação viva — Mailgun |
| NS | notify | ns3.lovable.cloud · ns4.lovable.cloud | delegação órfã · SERVFAIL hoje |
| A | @ | 185.158.133.1 | site principal · Lovable |
| A | analise | 185.158.133.1 | site ativo · responde 200 |
| CNAME | www | base44.onrender.com | quebrado hoje · 409 |
| CNAME | email | email.secureserver.net | webmail GoDaddy |
| CNAME | secureserver1._domainkey | s1.dkim.cartazista_online.8fe.onsecureserver.net | DKIM |
| CNAME | secureserver2._domainkey | s2.dkim.cartazista_online.8fe.onsecureserver.net | DKIM |
| MX | @ | 0 smtp.secureserver.net | caixa principal |
| MX | @ | 10 mailstore1.secureserver.net | caixa principal |
| MX | send | 10 feedback-smtp.us-east-1.amazonses.com | bounces SES |
| MX | suporte | 10 inbound-smtp.sa-east-1.amazonaws.com | inerte — ver nota |
| MX | send.suporte | 10 feedback-smtp.sa-east-1.amazonses.com | inerte — ver nota |
| TXT | @ | v=spf1 include:secureserver.net -all | SPF |
| TXT | _dmarc | v=DMARC1; p=none; pct=100; rua=mailto:dmarcreports@lovable.dev | DMARC |
| TXT | _dmarc.mail | mesmo valor acima | DMARC |
| TXT | _lovable | lovable_verify=6a6a7c3a…9831111a | prende o domínio à Lovable |
| TXT | _lovable.analise | lovable_verify=473f46df…516f638b | prende o site de análise |
| TXT | _lovable-email | lovable_email_verify=8a441bad…68a1a43aa | verificação de e-mail |
| TXT | _lovable-email | lovable_email_verify=9c76d86e…5e4899a2 | segundo TXT no mesmo nome |
| TXT | _lovable-email.mail | lovable_email_verify=4ed270d0…d923edf1 | verificação de e-mail |
| TXT | send.suporte | v=spf1 include:amazonses.com ~all | inerte — ver nota |
| TXT | resend._domainkey.suporte | p=MIGfMA0GCSqGSIb3… | DKIM Resend · inerte |
| SRV | _autodiscover._tcp | 0 0 443 autodiscover.secureserver.net | Outlook autodiscover |
Por que quatro registros estão marcados como "inerte"
suporte está delegado à Lovable — e quando um nome é delegado, tudo que a zona pai declara abaixo dele é ignorado. Os nameservers da Lovable respondem MX do Mailgun para suporte, não o Amazon SES que está no arquivo da GoDaddy. O mesmo vale para send.suporte e o DKIM do Resend: estão no zone file, mas ninguém os enxerga.
Replique todos assim mesmo. Não somos nós que decidimos o que é lixo na infraestrutura do cliente — se a Lovable um dia remover a delegação, esses registros voltam a valer, e a zona precisa estar fiel ao que existia. Fidelidade ao arquivo é a regra; otimização fica para depois, com o cliente ciente.
Supabase: risco zero, confirmado
Nos 31 registros não há nenhum apontando para o Supabase. O app fala com ele por *.supabase.co, fora da sua zona. A migração não tem como afetá-lo.
O risco número 1: perder uma delegação NS
suporte e notify.mail são delegações vivas, com MX do Mailgun por trás — é e-mail transacional do SaaS rodando ali. Se esses registros NS não forem recriados na Cloudflare, os subdomínios simplesmente deixam de existir e o e-mail transacional para, sem que o site apresente qualquer sintoma.
Confirmei na documentação da Cloudflare que delegação por registro NS funciona no plano Free — a tabela de disponibilidade marca "Yes" de Free a Enterprise, com limite de 10 nameservers por delegação (temos 2). O que é Enterprise-only é o "Subdomain setup", que é outra coisa e não precisamos.
O risco número 2: o site de tráfego pago
analise.cartazista.online está no ar respondendo 200. Ele depende de duas coisas: o registro A e o TXT _lovable.analise. Perder o TXT faz a Lovable desvincular o domínio — o site cai, e não volta só recriando o A.
O risco número 3: a pegadinha do export da GoDaddy
No arquivo, o SRV aparece como _autodiscover._tcp.@ — com um @ literal no meio, que é um defeito conhecido do exportador da GoDaddy. Ao importar, isso pode virar o nome errado _autodiscover._tcp.@.cartazista.online. Confira esse registro à mão depois do import — o nome correto é _autodiscover._tcp.
Duas coisas que já estão quebradas — registre antes de migrar
www devolve 409 e falha o TLS. notify devolve SERVFAIL: a delegação existe, mas a Lovable não tem zona para esse nome — é delegação órfã. Nenhum dos dois é culpa da migração, e ter isso documentado agora evita a conversa errada depois.
A regra que governa tudo: migrar com todos os registros cinza (DNS only). Assim a Cloudflare só troca quem responde as queries — o caminho do tráfego continua idêntico. Nada muda para o visitante, para a Lovable, para o Mailgun ou para o e-mail. O proxy entra depois, num registro só, com teste imediato e volta em segundos.
Adicione cartazista.online (o apex), plano Free. Deixe o quick scan rodar, mas não confie nele: a documentação da Cloudflare avisa que ele não garante encontrar tudo, e no seu caso há três delegações NS e nove TXT com underscore — exatamente o que ele costuma perder.
Em DNS → Records → Import and Export → Import, suba o cartazista.online.txt. Desmarque a opção de proxiar os registros importados.
O passo mais chato e o que evita todos os problemas. Confira nesta ordem de importância: primeiro as 3 delegações NS, depois os 2 DKIM, depois os 4 TXT de verificação da Lovable (incluindo os dois registros no mesmo nome _lovable-email), depois os 5 MX, e por último o SRV com o nome corrigido.
Se a Cloudflare recusar algum registro ou converter uma delegação em outra coisa, pare e me mande o print antes de seguir.
Este é o passo que transforma a migração em rotina. Dá para perguntar direto ao nameserver da Cloudflare o que ele responderia — sem que ninguém esteja usando ele ainda. Se bater com a produção, a troca é segura por construção.
Me passe os dois nameservers que a Cloudflare te der e eu rodo a bateria completa nos 31 registros, comparando um a um com a produção atual. É rápido e é a última chance de pegar erro sem custo.
Domain Portfolio → cartazista.online → Nameservers → Change → I'll use my own nameservers. Substitua ns65 e ns66.domaincontrol.com pelos dois da Cloudflare.
De manhã, em dia útil — não porque o risco seja grande, mas porque se precisar falar com GoDaddy, Lovable ou Mailgun, você quer gente atendendo. Durante a propagação os dois lados respondem igual, e é por isso que a fidelidade da zona importa tanto.
Site principal: cartazista.online abrindo, login, app conversando com o Supabase. Site de análise: analise.cartazista.online respondendo 200. E-mail da caixa: mande um de fora para dentro e um de dentro para fora. E-mail transacional: dispare um e-mail real do sistema pelo suporte e confirme que chegou — é a frente que mais silenciosamente quebra.
Depois, mande um e-mail para o mail-tester.com e confira SPF, DKIM e DMARC passando os três. Em SSL/TLS, deixe em Full — nunca Flexible, que produz loop de redirecionamento porque a origem já força HTTPS.
Só depois de tudo acima estável. O Worker Route exige registro proxiado: sem a nuvem laranja no apex não existe cartazista.online/tracking/web.js.
Ligue o laranja só no A do apex — nunca nas delegações NS, que não aceitam proxy, nem no analise, que não precisa. Recarregue o site na hora. O apex já responde com Server: cloudflare, então isso é Cloudflare na frente de Cloudflare: costuma funcionar, mas é o cenário que produz Error 1000. Deu 1000, 525 ou 526, volte para cinza — resolve em segundos.
Rollback, em uma frase
Enquanto o registrador continuar na GoDaddy, o desfazer é sempre o mesmo: voltar os nameservers para ns65 e ns66.domaincontrol.com. Por isso não mexemos em transferência de registrador agora — ela fecharia essa porta.
Sua tabela entra como segunda linha de defesa, não primeira. A Hotmart já resolve sozinha: o payload de compra aprovada traz o contador de recorrência (1 na primeira cobrança, 2+ nas seguintes) e o código do assinante, estável entre elas — que mapeiam direto no billing_type e no subscription_id que a Meta espera.
A Ticto eu preciso ver: o parser atual só olha status = authorized e não extrai nada de assinatura. Dois payloads reais — um de venda nova e um de renovação — e eu mapeio.
Onde a sua tabela é insubstituível é no cliente que já era cliente antes do tracking existir. Nenhum payload resolve isso, e é exatamente o que a sua lista da Ticto e da Hotmart cobre. O desenho final: o payload decide, a tabela confirma e cobre o legado.
A armadilha que quebraria tudo em silêncio
A deduplicação da Meta é por event_id + event_name em janela de 48h. Derive o event_id do ID da fatura, nunca do ID da assinatura — senão toda renovação carrega o id da aquisição. E note os papéis opostos: order_id é a fatura (único por cobrança), subscription_id é a assinatura (estável entre cobranças).
suporte e analiseSei que estão vivos e o que respondem, mas não o que quebra do lado do negócio se saírem do ar por dez minutos.