Feature Requests

MCP server para uso de endpoints via ChatGPT, Codex, Claude, Claude Code, etc., visando tanto uso não técnico, como também apoio a desenvolvedores que gostariam de criar integrações com a Snov.io de forma semelhante ao que temos na Apollo.io e Clay hoje. Sugestão de arquitetura: descoberta -> busca -> validação Stack sugerido: TypeScript para o MVP, Go para produção Referência: Shopify Dev MCP / Shopify Storefront MCP / Apollo MCP / Clay MCP / Apify MCP O objetivo é tornar a Snov.io um cidadão de primeira classe no ecossistema crescente de agentes de IA e ferramentas de desenvolvimento baseadas em LLM, e ao mesmo tempo resolver um problema específico da Snov.io e muito mais crítico do que é para a Shopify: proteger os clientes contra consumo acidental de créditos quando LLMs interagem com a API, bem semelhante ao que Apollo e Clay tem hoje. Venho construindo um protótipo privado exatamente desse tipo de servidor nas últimas semanas, e o que segue é uma descrição do que ele faz, por que isso importa, e por que acredito que seria um bom investimento de produto a Snov.io assumir isso oficialmente em vez de deixar para a comunidade. O padrão da Shopify funciona para a Snov.io com uma adaptação fundamental. A Shopify cobra por plano mensal, então uma LLM que entra em loop sem cuidado não custa nada a mais para o desenvolvedor. A Snov.io cobra por operação. Cada email verificado, cada busca por domínio, cada perfil do LinkedIn enriquecido é um crédito a menos. Um agente LLM autônomo que entenda mal um pedido do usuário e decida "verificar todos os 10.000 emails desta lista, por garantia" pode drenar uma conta paga em segundos. O mesmo vale para qualquer agente que faça retry de uma chamada com erro, rode sem deduplicação ou itere sobre uma lista de domínios sem limite rígido. Isso não é um risco teórico. É a razão mais importante pela qual desenvolvedores hesitam em colocar a Snov.io por trás de agentes autônomos hoje. Se o cliente precisa supervisionar cada chamada da LLM para garantir que o orçamento não exploda, a API deixa de ser útil para automação, que é justamente o caso de uso em que a Snov.io brilharia mais. Um servidor MCP oficial é o lugar natural para resolver isso...

Conectar com Agentes IA, para automações.

Problem Description: Currently, Snov only provides aggregate data regarding link clicks in email campaigns. There is no way to identify which specific lead has clicked on a specific link (e.g., a meeting booking link). This creates a significant blind spot in our sales and lead qualification workflow, as we cannot distinguish between an interested lead and a generic click. We need to know who is engaging to ensure effective follow-up. Proposed Solution: I propose adding support for dynamic variable placeholders within the link URLs in email campaigns. If Snovio allowed users to append custom variables—such as {lead_id}, {email}, or custom CRM identifiers—to the URLs (e.g., example.com/booking?email={email} ), the tracking could be resolved on the user's side (via their own website analytics or CRM). Why this is valuable: Low Technical Barrier: This solution requires minimal effort from the Snovio engineering team compared to building a custom in-app reporting dashboard for individual link clicks, as the data processing is handled on the user’s end. High Impact for B2B: This is a standard requirement for effective B2B marketing and sales automation. Enabling this would significantly increase the utility of Snovio, moving it from a "sending tool" to an integrated part of a high-performance sales stack. Universally Beneficial: This feature would provide immense value to any Snovio user who needs to connect their email outreach with website behavior and lead scoring, not just our specific use case. I hope this feature can be prioritized in the upcoming roadmap, as it would solve a critical workflow bottleneck for us and many other professional users. Pro-tip: When you submit this via their "Request a feature" portal, if there is a character limit or a "Details" section, you can use the structure above. It clearly articulates the "what" and the "why" without sounding overly demanding.

Trabalho com campanhas de volume bem alto, é bem comum a caixa de entrada ficar poluida por bounce. Gostaria de visualizar somente emails de respostas (RE:, RES:)

When a lead replies to an email, I have to manually search for the same lead in the campaign settings to double check that they have the Replied status. This is because sometimes they reply by composing a new email from a different email address. In this case the campaign doesn't know they replied. It would be so much easier for me if the Active/Replied/Pause status options dropdown was also displayed on the lead profile page as well. I could quickly change their status right from their profile page. As it is now, I have to manually copy/paste their name or email into the campaign settings. This is a flaw in the system that needs to be fixed.

The /v2/li-profiles-by-urls/result endpoint currently returns the lead's current position(s)/role at their company, but doesn't include past positions (work history). Problem: for outbound personalization, ICP scoring, and buying-intent analysis based on career trajectory, past roles are just as important as the current one. Knowing a lead's career path (previous companies, roles, tenure, industry transitions) is often what signals relevant context for outreach — e.g., someone who recently moved from a competitor, was promoted into a decision-making role, or has relevant domain experience from earlier roles. Request: extend the endpoint's response to include the full work history (past positions), not just the current one. Expected fields per past position: Company name Company LinkedIn URL/domain (if available) Job title Start date / end date (or duration) Location (if available) Description (if available) Additional request — optional email lookup parameter: There's currently no dedicated endpoint to find and verify an email address directly from a LinkedIn profile URL (see related feature request). It would be very valuable if this endpoint also supported an optional parameter (e.g. include_email: true ) to return the email lookup result (address + verification status) together with the profile data in the same call. Why combine them: profile data and email are both commonly needed for the same lead in outbound workflows. Being able to request both in a single call would reduce the number of API calls needed per lead and simplify enrichment pipelines. **Expected additional response fields (when include_email is set):** Email address Email verification status (valid/invalid/unknown) Source/confidence score (if available) Business justification: enables richer profile-based personalization, trajectory analysis, and intent scoring directly from the API response, without needing to scrape or reconstruct work history through other means — and, combined with optional email lookup, reduces the number of calls needed to fully enrich a lead in one pass. Use case: RevOps/outbound workflows that score and personalize messaging based on a lead's career path (job changes, tenure patterns, industry moves) as a proxy for buying intent and relevance, while also needing a verified contact email for the same lead.