BK-233 - Criação dinâmica de evento no Facebook

Objetivo

• estudar uma forma de criar evento no Facebook de maneira dinâmica
• evitar que o admin tenha de criar manualmente cada evento pelo fluxo padrão do Facebook

Contexto

• link de referência atual do fluxo manual:
• https://www.facebook.com/events/create?...
• a ideia é descobrir se conseguimos preencher/acionar esse fluxo de forma automatizada ou semi-automatizada a partir dos dados já existentes no Rio no Teatro

Perguntas a responder depois

• existe forma segura e estável de pré-preencher esse fluxo?
• isso depende de automação de navegador autenticada?
• existe alguma API oficial ou integração suportada que substitua o fluxo manual?
• quais dados do evento no RNT já estão prontos para alimentar essa criação?

Escopo inicial do lembrete

• avaliar viabilidade técnica
• mapear riscos de bloqueio/termos de uso
• decidir se a trilha correta é:
• API oficial
• browser automation
• helper semi-manual para abrir o fluxo já preenchido

Resultado esperado no futuro

• ou uma automação real de criação
• ou um atalho operacional confiável que reduza drasticamente o trabalho manual do admin

Leitura cruzada via worker externo - OpenCode

Atualizado em: 2026-04-08 02:53 -03

1. Caminhos possíveis

• Graph API (POST /{user-id}/events)
• leitura do worker: API pública de criação de eventos foi descontinuada para esse uso
• Official Events API
• leitura do worker: disponível só para parceiros/plataformas aprovadas pela Meta
• Browser automation
• tecnicamente possível via navegador autenticado
• dependente de sessão logada e sujeito a quebra por mudanças de UI
• Helper semi-manual com URL
• leitura do worker: o fluxo events/create não garante pré-preenchimento estável dos campos relevantes

2. Riscos e limites

• alto risco de bloqueio/anti-bot ao automatizar conta do Facebook por browser
• ausência de endpoint oficial público e estável para criar evento como queremos
• manutenção alta por depender de UI/DOM de terceiro
• risco de conflito com termos de uso/política da plataforma

3. Recomendação do worker

• não tratar como automação principal por API pública
• se essa frente voltar a ser prioridade, avaliar:
• parceiro/oficial API
• browser automation autenticada apenas como experimento controlado
• helper operacional sem prometer automação total

4. Próximos passos sugeridos

• documentar a inviabilidade/alto risco como ponto de partida
• mapear se existe algum caminho oficial de parceiro que faça sentido para o RNT
• só considerar automação por browser se a operação aceitar risco de manutenção e bloqueio

Leitura cruzada via worker externo - Gemini

Atualizado em: 2026-04-08 02:53 -03

• sessão externa aberta para vasculhar integrações internas do projeto relacionadas a Facebook e possíveis ganchos já existentes
• até este ponto, o worker ainda estava explorando módulos e artefatos do projeto e não entregou parecer conclusivo pronto para anexar como decisão
• se a leitura devolver algo realmente novo e útil, complementar este BK depois