Skip to main content
O conector MeetGeek lê as reuniões gravadas no MeetGeek, os times da conta e, de cada reunião, a transcrição e o resumo com os highlights. Cada reunião e os documentos dela ficam visíveis para o anfitrião da reunião.

Capacidades

  • Traz ao Data Catalog os metadados de cada reunião (título, anfitrião, participantes, início e fim, idioma, origem, template e evento de calendário) e os times da conta.
  • Publica cinco modelos limpos: meetgeek_meetings, meetgeek_hosts, meetgeek_meeting_participants, meetgeek_meeting_teams e meetgeek_teams, com datas em UTC e e-mails em minúsculas.
  • Alimenta o Memory pelo fragmento de ontologia do conector. As reuniões viram nós Meeting e os anfitriões viram nós Agent, ligados por “organizada por”. Cada participante se liga à reunião por “participou de” quando o e-mail dele já existe no grafo, vindo de outro conector. A reunião entra na linha do tempo pela data de início. Os anfitriões se unem às pessoas do HubSpot, Jira, Zendesk e ClickUp pelo e-mail. Os nós só entram no grafo depois que a ontologia unificada é aplicada.
  • Envia ao Knowledge a transcrição e o resumo de cada reunião, como dois documentos de texto com o link da reunião no MeetGeek.
  • Grava a permissão de cada reunião e de cada documento a partir do anfitrião (ver Permissões).

Recursos disponíveis

Nenhum recurso tem cursor por data. A API do MeetGeek não filtra a listagem por data, e uma gravação enviada hoje pode ter data antiga. O conector guarda, por isso, a lista das reuniões já sincronizadas e o estado de cada documento delas (ver Como a sincronização funciona). Na criação pelo Console, os quatro recursos e as tabelas clean nascem ligados. meetings não pode ser desligado: a permissão dos documentos vem do anfitrião, que só aparece no detalhe da reunião. Você pode desligar transcripts ou summaries no Data Catalog para gastar menos requisições. A transcrição é a parte mais cara, com uma requisição por bloco de 500 falas. O link de cada documento é https://app.meetgeek.ai/meeting/<meeting_id>, e o título é o título da reunião. O campo join_link da reunião nunca é gravado, porque pode conter a senha da sala.

Como ler os dados

  • external_id de meetgeek_meetings é o meeting_id do MeetGeek. started_at e ended_at estão em UTC. timezone é o fuso da reunião, só informativo.
  • meeting_source é a origem da reunião no MeetGeek (convite de calendário, envio de arquivo). A coluna foi renomeada de source porque o Memory usa source para o nome do conector.
  • event_id é o id do evento de calendário. Fica NULL em reunião instantânea e em gravação enviada por arquivo.
  • meetgeek_hosts tem um anfitrião por linha. external_id e email trazem o mesmo e-mail, porque a API do MeetGeek não tem id de usuário. phone é sempre NULL.
  • meetgeek_meeting_participants tem uma linha por reunião e e-mail de participante, sem repetição. O anfitrião não entra nessa tabela, a não ser que o MeetGeek o liste também como participante.
  • meetgeek_meeting_teams tem uma linha por reunião e time com acesso a ela. team_id se liga a meetgeek_teams.external_id.
  • Duas pessoas gravando a mesma call geram duas reuniões, cada uma com o próprio meeting_id e o próprio anfitrião. As duas compartilham o event_id quando a call veio de um convite.

Permissões (ACL)

O conector lê a permissão de cada item na fonte e a guarda junto com o dado. Em Comportamento dos dados, você escolhe entre dois modos: No modo “Espelhar a fonte”, a Strattum reconhece o anfitrião pelo e-mail dele no MeetGeek. O conector grava esse e-mail como uma identidade do MeetGeek, ligada a esta conexão, e assume que a pessoa usa o mesmo e-mail na Strattum. O MeetGeek não tem a opção Exigir login na fonte como prova de identidade. No passo de acesso do assistente de criação, o Comportamento dos dados começa em “Aberto”.

Como a fonte define acesso

No MeetGeek, quem gravou a reunião é o dono dela. Ela pode ser compartilhada pelo convite de calendário, com uma pessoa específica, por link público ou por uma regra de time. A API informa o anfitrião, os e-mails dos participantes e os ids dos times com acesso a cada reunião. Ela não informa quem são os membros de cada time nem com quem a reunião foi compartilhada individualmente.

Como a Strattum traduz o acesso

Participantes e times não recebem acesso. Estar na call não é o mesmo que ter acesso à gravação no MeetGeek, e a API não lista os membros dos times. Um colega que vê a reunião no MeetGeek por um time ou por compartilhamento não a vê na Strattum no modo “Espelhar a fonte”. Se o seu time precisa dessas reuniões, use o modo “Aberto” e limite o acesso em Quem pode usar este conector.

Quando a identidade não é encontrada

  • Uma reunião sem anfitrião é gravada sem nenhum leitor. Ela fica invisível no modo “Espelhar a fonte”, e os documentos dela não são entregues ao Knowledge, em nenhum dos dois modos.
  • Quem usa na Strattum um e-mail diferente do que usa no MeetGeek não vê as próprias reuniões no modo “Espelhar a fonte”.

Quando a permissão é atualizada

A permissão de uma reunião é recalculada toda vez que o conector relê o detalhe dela: na primeira leitura, quando algum documento está pendente e numa releitura completa. O MeetGeek não muda o anfitrião de uma reunião. Se isso acontecer, a mudança só chega à Strattum numa releitura completa.

Pré-requisitos

  • Uma conta no MeetGeek, em qualquer plano com acesso à API.
  • A região da conta: EU ou US. A chave só vale na região que a emitiu.
  • A chave de API de um usuário. O conector vê só o universo desse usuário: as reuniões que ele gravou, as compartilhadas com ele e as dos times em que ele pode ver as reuniões dos membros. Ser admin no MeetGeek não amplia esse universo.
  • Recomendado: uma service account, um usuário MeetGeek dedicado à integração. Convide-o em cada time relevante com permissão de ver as reuniões dos membros, e habilite Share para cada membro na regra de compartilhamento do time. Times e compartilhamento por time existem nos planos Business e Enterprise.
  • Uma só conexão MeetGeek por instalação da Strattum.

Autenticação e escopos

A autenticação usa uma chave de API do MeetGeek, enviada no cabeçalho Authorization: Bearer <chave> para o endereço da região escolhida. A chave não tem escopos: ela lê o que o usuário que a gerou lê. O conector só faz leituras.
1

Entre com o usuário do conector

Acesse app.meetgeek.ai com o usuário cuja chave o conector vai usar, de preferência a service account.
2

Gere a chave

Abra Integrations e, no card Public API, gere a chave. Copie-a.
3

Anote a região

Confira se a conta foi aberta na região EU ou US. Uma chave de conta EU é recusada no endereço US.
A chave dá acesso a todas as reuniões que o usuário vê no MeetGeek. Guarde-a em local seguro e nunca a publique em repositórios.

Configuração no Console

1

Abra o assistente

Em Conectores, crie uma nova conexão e selecione MeetGeek.
2

Preencha a conexão

Nome do Conector (Opcional): como a conexão aparece na lista. O padrão é MeetGeek.Região (Obrigatório): “EU (api-eu.meetgeek.ai)” ou “US (api-us.meetgeek.ai)”. O padrão é EU.API Key (Obrigatório): a chave gerada no card Public API.
3

Teste a conexão

Clique em Testar Conexão. Você só avança depois de um teste com sucesso. O teste faz uma única requisição: lista uma reunião no endereço da região. Uma conta sem reuniões passa. Se a cota do dia já acabou, o teste passa com um aviso, e você pode salvar.
4

Escolha a frequência

Em Frequência de Sincronização (Obrigatório), escolha a frequência. A opção recomendada é “Diário às 06:00 (UTC)”.
5

Defina o acesso

Em Permissionamento, defina Quem pode usar este conector (Obrigatório) e o Comportamento dos dados (Obrigatório). O padrão é “Todos os usuários” e “Aberto”.
6

Revise e salve

Em Revisão, confira os dados e salve. Depois, no Data Catalog, desligue os recursos que você não quer carregar e marque os dados pessoais. Ver Dados pessoais (PII).
Na edição do conector, a chave e a região salvas não aparecem. Para trocar a chave, informe a nova chave e escolha também a região dela, senão o salvamento fica bloqueado.
As transcrições e os resumos só aparecem na busca quando um contexto do Knowledge inclui o conector. O contexto recebe todas as reuniões do MeetGeek, sem recorte por time.

Como a sincronização funciona

A frequência vem do passo Frequência de Sincronização. A referência do conector é uma execução por dia, às 06:00 UTC. Rodar mais vezes só gasta a cota mais cedo nos planos Free e Pro. Além dela, roda uma verificação por dia, às 03:00 por padrão, que o conector trata como uma execução normal. Ordem. Em cada execução, o conector lê os times da conta e lista todas as reuniões, juntando a listagem do usuário da chave com a de cada time em que ele pode ver as reuniões. Depois busca, nesta ordem:
  1. Reuniões novas e reuniões com documento pendente, das mais recentes para as mais antigas. Para cada uma, lê o detalhe e os documentos ligados (transcrição e depois resumo).
  2. Reuniões dos últimos 7 dias: só o resumo, para pegar um resumo que mudou ou chegou depois da reunião.
  3. Com a cota que sobra, as reuniões mais antigas: só o resumo, começando pela verificação mais antiga.
Um resumo verificado há menos de 20 horas não é verificado de novo. Quando o resumo mudou, o conector relê o detalhe e os highlights e reenvia o documento. Custo. Cada execução gasta uma requisição com os times, uma para cada 500 reuniões listadas e uma por time. Uma reunião nova custa cerca de 4 requisições: o detalhe, uma por bloco de 500 falas da transcrição, o resumo e os highlights. No plano Free ou Pro, com 100 requisições por dia, isso dá cerca de 20 reuniões novas por dia, e a primeira carga de uma conta grande leva dias. Paginação. As listagens e a transcrição são lidas em páginas de 500 itens, seguindo o cursor da API até ele vir vazio. Cota diária esgotada. Quando o MeetGeek responde que a cota do dia acabou, o conector para sem erro. A execução termina como concluída, o que não foi buscado fica pendente, e o sync seguinte retoma de onde parou. O log da execução registra o corte e quantas reuniões ficaram pendentes. Se a cota acabar ainda na listagem, nada é buscado e o estado anterior é mantido. Escrita. meetings é mesclado pelo meeting_id: a execução só regrava as reuniões que leu. teams é substituído por inteiro em toda execução. Depois da escrita, as tabelas clean são reconstruídas. Ligar um documento depois. Se você liga transcripts ou summaries depois que meetings já tem histórico, toda reunião volta a ficar pendente para esse documento. O conector relê o detalhe e busca o documento de todas elas, o que gasta cota e, no plano Free ou Pro, leva dias. Ligar o Knowledge depois. Se o conector sincronizou antes de existir um contexto do Knowledge com ele, o Knowledge recusa os documentos dessas execuções. Quando você inclui o conector num contexto, o Knowledge pede uma releitura completa, e o conector busca de novo o detalhe e os documentos de todas as reuniões, com o mesmo custo em cota. Releitura completa. Um Full Refresh pedido em Data Pipelines marca todas as reuniões como pendentes e relê detalhe e documentos de cada uma. A releitura avança pelo mecanismo normal e, no plano Free ou Pro, termina ao longo de vários dias. É a forma de recuperar um resumo refeito no MeetGeek que a verificação diária não alcançou. Mudança de dados pessoais. Quando a marcação de dados pessoais de meetings muda no Data Catalog, o conector relê o detalhe de todas as reuniões, sem buscar os documentos de novo. Reunião inacessível. Se o MeetGeek recusa o detalhe de uma reunião (resposta 403), ela não é gravada e o conector tenta de novo depois de 20 horas. Remoção. Uma reunião apagada no MeetGeek continua na tabela meetings. No Knowledge, os documentos dela só saem numa execução completa: uma releitura que revisitou todas as reuniões sem corte de cota, com transcripts e summaries ligados. No plano Free ou Pro, isso quase nunca acontece. Ver Atualização e remoção de documentos. Documentos sem conteúdo. Um resumo ou uma transcrição vazia não vira documento. O resumo vazio continua sendo verificado pela janela de 7 dias e pela verificação das reuniões antigas. A transcrição vazia só é buscada de novo numa releitura completa. Uma falha ao buscar um documento mantém no Knowledge a última versão boa, e o documento fica pendente para a execução seguinte.

API da fonte

Todas as chamadas são GET no endereço da região: https://api-eu.meetgeek.ai ou https://api-us.meetgeek.ai. Rate limits. O MeetGeek aceita 100 requisições por dia nos planos Free e Pro, e 100 por minuto nos planos Business e Enterprise. A documentação não descreve a resposta ao limite. Na prática, o MeetGeek responde 429 com a unidade do limite (dia ou minuto) no corpo, sem cabeçalho Retry-After e sem cabeçalho de cota. O conector envia no máximo 90 requisições por minuto, numa janela móvel, e no máximo 5.000 por execução. Cada requisição espera até 30 segundos. Diante de um 429 de cota diária, ele para a execução sem erro (ver Como a sincronização funciona). Diante de outro 429, repete a mesma chamada depois de 5, 10 e 20 segundos, até 4 tentativas no total. Esgotadas as tentativas, ou numa falha de rede, que não é repetida, a leitura da reunião ou do documento falha e fica pendente para a execução seguinte. Se a falha for na listagem de um time, as reuniões desse time ficam de fora da execução. Se for na leitura dos times ou na listagem principal, a execução inteira falha. Referência oficial: MeetGeek, Limits

Limitações conhecidas

  • Nos planos Free e Pro, com 100 requisições por dia, entram cerca de 20 reuniões novas por dia. A primeira carga de uma conta grande leva dias, e cada execução cortada pela cota aparece como concluída.
  • A chave vê só o universo do usuário que a gerou. Com a chave de uma pessoa, o conector traz só as reuniões dela e as compartilhadas com ela. Use uma service account convidada nos times.
  • A permissão é só do anfitrião. Participantes, times e compartilhamentos individuais não dão acesso na Strattum no modo “Espelhar a fonte”.
  • Uma reunião apagada no MeetGeek continua nas tabelas. No Knowledge, os documentos dela só saem numa execução completa, que no plano Free ou Pro quase nunca acontece.
  • Ligar transcripts ou summaries, ou incluir o conector num contexto do Knowledge, depois do primeiro sync faz o conector buscar de novo os documentos de todas as reuniões, o que custa cota.
  • Desligar transcripts ou summaries impede execuções completas, e documentos de reuniões apagadas não saem do Knowledge.
  • A transcrição não é relida depois da primeira busca, e uma mudança de anfitrião não é recapturada. As duas só chegam numa releitura completa.
  • O formato dos times na API não foi confirmado com uma conta real que tenha times. Um time em formato diferente do esperado é pulado, as reuniões que só ele lista ficam de fora, e a execução não se declara completa. Hoje a tabela meetgeek_teams costuma ficar vazia.
  • O link do documento foi confirmado só numa conta EU. Numa conta US, o endereço do app não foi verificado.
  • Duas pessoas gravando a mesma call geram duas reuniões, e contagens de reuniões podem sair infladas.
  • Insights por reunião, o download da gravação, o envio de arquivos e os webhooks do MeetGeek não são usados.
  • O conector não mascara dados pessoais dentro das transcrições e dos resumos. host_email e participant_emails de meetings são sugeridos para mascaramento como e-mail, e title como texto livre, no painel de dados pessoais do Data Catalog. Nada é mascarado até você aplicar a sugestão e salvar.
  • O MeetGeek não permite vincular a conta de cada usuário: a identidade é o e-mail do anfitrião no MeetGeek.
  • Cada instalação tem uma só conexão MeetGeek.

Troubleshooting

Próximos passos

Data Catalog

Escolha os recursos do MeetGeek e marque os dados pessoais.

Knowledge

Veja como as transcrições e os resumos do MeetGeek são indexados e buscados.
O conector não lê credenciais de variáveis de ambiente. A chave e a região são gravadas por conexão, quando você cria a conexão no Console, com as chaves MEETGEEK_API_KEY e MEETGEEK_REGION (eu ou us). Para testar localmente, suba o ambiente pelo guia de desenvolvimento local e crie a conexão pelo Console desse ambiente.