# Runrun.it para data warehouse: projetos, tarefas e produtividade > Conector gerenciado para sincronizar boards, tasks, clients e tempo trabalhado do Runrun.it para BigQuery, Redshift e Databricks. Source: https://www.erathos.com/blog/conector-runrunit-lancamento Published: 2026-07-29 Category: Novos Conectores ![](https://cms-media.erathos.com/AuS1MOWsM0aZvGvCqrIyNgrfMGw-1.png) ## Conector do Runrun.it: sincronize projetos e tarefas com o warehouse sem manter pipeline [Runrun.it](http://runrun.it/) é uma das plataformas de gestão de projetos e processos mais usadas no Brasil. Times de operações, marketing, TI e financeiro registram tarefas, prazos, tempo trabalhado e fluxos de aprovação todos os dias dentro da ferramenta. Quando alguém no time de dados precisa dessas informações no warehouse, o caminho mais comum é escrever um script que chama a API do Runrun.it, pagina os resultados e carrega tudo em uma tabela. A primeira versão desse script funciona. O problema aparece nas semanas seguintes: - **Paginação não uniforme**: a API do Runrun.it pagina resultados de formas diferentes dependendo do endpoint. Um endpoint retorna 50 itens por página, outro retorna 200. Tratar todos os casos no mesmo script gera silenciosamente dados truncados quando um endpoint muda de comportamento. - **Rate limit silencioso**: a API pode restringir o número de requisições por minuto sem retornar um erro HTTP explícito. O script segue executando, mas recebe respostas vazias ou parciais. O pipeline marca sucesso, mas o dado no warehouse está incompleto. - **Schema evolution sem aviso**: o Runrun.it pode adicionar, renomear ou remover campos de um endpoint a qualquer momento. O script que espera um schema fixo quebra ou, pior, ignora campos novos que a análise precisaria. - **Falta de observabilidade**: ninguém sabe quando o pipeline rodou pela última vez, quantos registros foram carregados em cada execução, ou se houve falha parcial. Não existe log estruturado, não existe alerta. A primeira pista de que algo está errado chega quando um dashboard mostra números que não bater. O cenário mais grave não é o pipeline que quebra com um erro de autenticação. É o pipeline que executa com sucesso, entrega dados incompletos ou desatualizados, e alimenta decisões erradas sem que ninguém perceba. ## O que é possível fazer quando os dados do Runrun.it chegam no warehouse ### Análise de produtividade por equipe e por pessoa Com as tabelas `tasks`, `users` e `manual_work_periods` no warehouse, é possível calcular tempo trabalhado por usuário, taxa de entrega e throughput por equipe. Esses indicadores só fazem sentido quando cruzados com o tempo registrado em cada tarefa, o que requer os dados em um banco relacional onde você consegue rodar aggregations complexas sem depender dos dashboards nativos do Runrun.it. ### Gestão de SLA e cumprimento de prazos A tabela `tasks` traz `desired_delivery_date` e `delivered_at`. No warehouse, é possível calcular o atraso médio por projeto, por cliente e por tipo de tarefa, identificar padrões recorrentes de estouro de prazo e montar alertas analíticos que cruzam dados do Runrun.it com outros sistemas. Isso não é possível dentro da ferramenta, onde a análise fica limitada aos filtros e relatórios nativos. ### Visão de capacidade vs. demanda Cruzando `tasks` em andamento por `user_id` com `time_worked` e `current_estimate_seconds`, o time de operações consegue visualizar a carga real de cada pessoa e identificar gargalos de capacidade antes que virem atrasos. Essa análise, no warehouse, pode ser combinada com dados de folha, HRIS ou CRM para entender custo de entrega por pessoa e por cliente. ### Análise de fluxo de trabalho por board A relação entre `boards`, `board_stages` e `tasks` permite medir quanto tempo cada tarefa spende em cada estágio do fluxo. No warehouse, dá para calcular cycle time por board, identificar estágios que acumulam tarefas e comparar a performance de diferentes fluxos de trabalho lado a lado, algo que os relatórios nativos não entregam de forma consolidada. ### Cruzamento com CRM e financeiro A tabela `clients` e `projects` do Runrun.it pode ser cruzada com dados de CRM para entender o custo de entrega por cliente, o esforço investido por conta e a margem real de cada projeto. Conectar dados de gestão de projetos com dados financeiros e de vendas só é viável quando ambos estão no mesmo warehouse, em tabelas relacionais que o time de dados controla. ### Análise de tempo trabalhado por tipo de tarefa A tabela `manual_work_periods`, com `task_id` e `duration_seconds`, permite segmentar o tempo trabalhado por `task_type`, `project` e `tag`. No warehouse, é possível responder perguntas como "quanto tempo gastamos em tarefas do tipo X no cliente Y no último trimestre" e usar essas respostas para precificar projetos futuros. ## O que está disponível no conector Endpoint O que contém boards Boards cadastrados no Runrun.it, com nome e timestamps de criação e atualização. É o endpoint pai de board\_stages. board\_stages Estágios de cada board, vinculados ao board pai via board\_id. Permite mapear o fluxo de trabalho de cada board. clients Clientes cadastrados na organização, com status ativo/inativo e vínculo com a organização. É o endpoint pai de projects. manual\_work\_periods Períodos de trabalho manuais registrados por usuário em cada tarefa, com duração em segundos e timestamps de início e fim. Suporta sincronização incremental via cursor created\_at. projects Projetos vinculados a clientes, com status ativo/inativo e visibilidade pública. É o endpoint pai de tasks. tags Tags de organização criadas na conta, para categorização de tarefas e projetos. task\_types Tipos de tarefa cadastrados, com status ativo/inativo. Usados para classificar tarefas dentro de cada projeto. tasks Tarefas com título, prazos desejados (start, delivery, date), data de entrega, estimativa atual, tempo trabalhado, status (working on, overdue), vínculos com project, user, type, board e board\_stage. Suporta sincronização incremental via cursor updated\_at. teams Equipes cadastradas na organização, com nome e timestamps. users Usuários da conta, com nome, email, avatar, status ativo, flags de admin e master, tipo, idioma e fuso horário. ## Como autenticar A autenticação do conector do Runrun.it na Erathos requer duas credenciais: - **App-Key**: identifica a sua conta no Runrun.it. Para encontrar, acesse o Runrun.it e navegue até **Manage > Integrations > API Integration**. A App-Key aparece na página de integrações. - **User-Token**: token pessoal de API que autentica requisições em seu nome. Para gerar, clique no seu avatar no canto superior direito, selecione **My Account > API** e gere um novo token pessoal se ainda não existir um. Copie o valor. Cole as duas credenciais nos campos **App-Key** e **User-Token** na plataforma da Erathos e clique em **Save and close** para concluir a configuração. Consulte a documentação completa em [docs.erathos.com/connectors/apis/runrun.it](https://docs.erathos.com/connectors/apis/runrun.it). ## Por que terceirizar a ingestão para a Erathos ### Visibilidade ponta a ponta de cada execução A Erathos registra cada execução do pipeline com timestamp, número de registros lidos, número de registros gravados, duração e status. O time de dados consegue ver o histórico de execuções sem precisar construir logging do zero. Quando algo muda no schema do Runrun.it, a Erathos detecta e reporta, em vez de falhar silenciosamente. ### Alertas configurados de fábrica O pipeline vem com alertas pré-configurados para falhas de execução, variações anormais de volume de dados e problemas de autenticação. Ninguém precisa escrever regras de monitoramento nem configurar integrações com Slack ou PagerDuty do zero. Se o token do Runrun.it expirar ou a API começar a retornar erros, o time é notificado. ### Reprocessamento como operação suportada Quando uma execução falha ou carrega dados incompletos, a Erathos permite reprocessar a execução inteira ou um período específico com um clique. Não é necessário reescrever o cursor manualmente, ajustar o script ou pedir acesso de administrador para rodar o pipeline de novo. O reprocessamento é uma operação de primeiro class na plataforma. ## Pipelines disponíveis - Runrun.it → BigQuery: [https://www.erathos.com/pipelines/runrun-it-bigquery](https://www.erathos.com/pipelines/runrun.it-bigquery) - Runrun.it → Redshift: [https://www.erathos.com/pipelines/runrun-it-redshift](https://www.erathos.com/pipelines/runrun.it-red-shift) - Runrun.it → PostgreSQL: [https://www.erathos.com/pipelines/runrun-it-postgresql](https://www.erathos.com/pipelines/runrun.it-postgresql) - Runrun.it → Databricks: [https://www.erathos.com/pipelines/runrun-it-databricks](https://www.erathos.com/pipelines/runrun.it-databricks) ## Comece agora [Crie sua conta na Erathos](https://app.erathos.com/signup?slug=blog&button=cta&utm_campaign=runrun.it_release) e conecte o Runrun.it ao seu warehouse em minutos. Com App-Key e User-Token, os primeiros dados chegam ao destino sem nenhum código de pipeline para escrever, manter ou monitorar. Dados de projetos, tarefas e tempo trabalhado gerados todo dia não deveriam ficar trancados em um SaaS, desconectados do restante do seu modelo analítico. Ou pior: em um pipeline caseiro que vai custar atenção do time todo mês para sempre. Veja a documentação completa do conector em [docs.erathos.com/connectors/apis/runrun.it](https://docs.erathos.com/connectors/apis/runrun.it).