Many sales teams and agencies outgrow “in-app” dashboards once they need cross-client reporting, multi-channel attribution, or a single source of truth across tools. If you already use a BI tool (Metabase, Looker, Power BI) or you centralize metrics in Google Sheets, the lemlist API can help you automate reporting and create consistent, trustworthy dashboards.
This article explains two proven approaches to reporting with the lemlist API—pulling campaign stats programmatically and capturing real-time events via webhooks—plus what to track, why sender disconnections matter, and a real agency example.
Why this matters
Outreach performance is easiest to improve when reporting is timely, consistent, and comparable across campaigns, senders, and clients. Without an automated reporting layer, teams typically run into the same issues: delayed insights, inconsistent metrics definitions, and too much manual work exporting data. Using the lemlist API lets you build scalable reporting that supports better decisions (what to scale, what to pause, and where deliverability risks are emerging).
Core principles (mindset) for API-based reporting
Decide whether you need “snapshots” or “events.”
Snapshot metrics (daily/weekly totals) are great for executive reporting. Event data (every open, reply, bounce) is better for deep analysis, alerting, and deliverability monitoring.Separate performance reporting from deliverability monitoring.
Response metrics (opens/replies) tell you about messaging and targeting; disconnections and bounce patterns often indicate deliverability or reputation issues that require different actions.Normalize data so it’s comparable.
If you report across multiple users, teams, or sending domains, make sure you store consistent identifiers and keep a clear mapping (campaign → client, sender → domain, user → team).Automate “decision signals,” not just dashboards.
The best reporting doesn’t only visualize results—it triggers actions (e.g., alert when disconnections spike, or when bounce rate crosses a threshold).
Two main ways to use the lemlist API for reporting
1) Get campaign stats programmatically (pull model)
When to use: You want reliable rollups (daily/weekly/monthly), lightweight implementation, or you mainly care about campaign-level performance.
How it works: Your system queries the lemlist API on a schedule (e.g., hourly/daily) and stores campaign stats in your reporting database or spreadsheet.
Why it works: Pulling campaign stats is simple to operationalize. It creates consistent “snapshots” that are easy to chart, compare across time periods, and share with stakeholders.
Best practices:
Pull on a consistent cadence (e.g., daily) and store results as time-stamped snapshots to support trend reporting.
Record the dimension you’ll need later (campaign ID, user, team, sending domain, client tag) so you can filter and compare.
Define metric formulas once (especially rates), then keep them consistent across dashboards and client reports.
2) Use the activity webhook to store data in your database (push model)
When to use: You need real-time reporting, advanced breakdowns, alerting, or you want a detailed activity history (events) to support deeper analysis.
How it works: You subscribe to lemlist activity updates via webhook. Each event is delivered to your endpoint in real time (or near real time). You store these events in your database and build reporting on top of them.
Why it works: Event data is the most flexible. It supports granular reporting (by user, by domain, by lead segment), and it enables “monitoring” use cases like deliverability alerts and operational QA.
Best practices:
Design for scale: store events in an append-only table (raw events), then build aggregated tables for dashboards.
Make ingestion resilient: handle retries, deduplicate events if needed, and log webhook failures so you don’t silently lose data.
Enrich data downstream: join events with campaign metadata (client, owner, ICP segment) so reports answer business questions, not just technical ones.
What to track: metrics that make reporting actionable
Campaign performance
Emails sent: volume by campaign, by day/week, by sender, by domain.
Open rate: directional indicator (useful for spotting major issues), but interpret carefully due to tracking limitations.
Reply rate: one of the most meaningful indicators of message-market fit and targeting quality.
Bounce rate: critical for list quality and deliverability hygiene; monitor by domain and lead source.
Breakdowns: by users, teams, sending domain, client, or campaign type (new outreach vs. follow-up vs. reactivation).
Sender disconnections (deliverability risk)
Disconnections by email: identify which inboxes are repeatedly getting flagged or hitting reputation problems.
Disconnections by domain: detect systemic issues (domain reputation, configuration, volume spikes, poor list quality).
Why disconnections deserve special attention: Sender disconnections often happen when inboxes are marked as spam or when deliverability signals degrade quickly. If you notice many disconnections in a short time window, it’s a strong signal to pause, investigate, and consider resting the domain (and reviewing list sources, copy, and volume ramp).
Common reporting scenarios & how to handle them
Scenario 1: Agency reporting across 10–50 clients
What’s happening: You need consistent KPIs and client-ready dashboards without manual exports.
How to respond: Use the webhook (events) for detailed data + scheduled pulls for campaign snapshots, then build standardized “client views” with filters by client/campaign tags.
Reporting tip: Create a single metrics layer (definitions for reply rate, bounce rate, etc.) so every client sees comparable numbers.
Scenario 2: RevOps wants a single source of truth in a BI tool
What’s happening: Outreach performance needs to sit next to CRM pipeline, revenue, and attribution.
How to respond: Store raw events in a warehouse (e.g., Snowflake/BigQuery), then model curated tables for dashboards (daily campaign performance, deliverability health, sender-level output).
Scenario 3: You want automated weekly email reports
What’s happening: Stakeholders want updates without logging into tools.
How to respond: Build a scheduled job that generates a weekly rollup (per client/campaign/team) and sends it via email (or Slack). A pull model is often sufficient if you only need summary data.
What NOT to do (common mistakes)
Mistake: Only tracking opens.
Why it backfires: Opens are noisy and can be inflated or undercounted.
Do this instead: Prioritize reply rate, bounce rate, and trend-based analysis.Mistake: No breakdown by sending domain/sender.
Why it backfires: Domain-level issues get hidden inside averages until performance drops sharply.
Do this instead: Always include sender and domain cuts for deliverability monitoring.Mistake: Building dashboards directly on raw webhook events only.
Why it backfires: Dashboards become slow and brittle as event volume grows.
Do this instead: Keep raw events, but power charts from aggregated tables.Mistake: Not alerting on disconnection spikes.
Why it backfires: You find out about deliverability problems after results drop.
Do this instead: Add thresholds and notifications (e.g., “X disconnections in Y hours”).
Practice this: build a reporting system that scales
Exercise 1: Define your KPI dictionary.
Write down your exact formulas for reply rate, bounce rate, and any “qualified reply” logic you use. Share it internally so everyone reports the same way.Exercise 2: Create a “deliverability health” dashboard.
Add charts for disconnections by day, disconnections by domain, and bounce rate by lead source. Decide what threshold triggers a pause.Exercise 3: Build one standardized client report template.
One page: volume, replies, bounces, top campaigns, bottom campaigns, and next actions. Reuse it across clients to reduce reporting overhead.
Real example: How GetScalability uses the lemlist API
Victor Alexandrian’s team at GetScalability, an agency managing 30+ active clients, uses a centralized analytics stack to visualize cold outreach activity and share transparent reporting with clients.
What they achieve by centralizing data:
See which leads still need enrichment
Identify top-performing campaigns faster
Build client-facing dashboards and analytics in one place
Their approach:
Use the lemlist API webhook to receive real-time activity updates.
Collect data using Stitch.
Store data in Snowflake.
Visualize everything in Metabase.
This workflow enables real-time views and automated reporting, improving transparency and operational efficiency across many campaigns and clients.
Measuring success (what “good” looks like)
Time-to-insight: How quickly you can detect a performance drop or deliverability issue (goal: same day, not end of week).
Reporting consistency: Stakeholders see the same numbers across tools (goal: one metric definition, one source of truth).
Deliverability response speed: Time between a disconnection spike and corrective action (goal: hours, not days).
Client reporting effort: Manual hours spent per report (goal: near-zero after setup).
Quick reference: choose the right approach
Need weekly/monthly rollups? Pull campaign stats programmatically.
Need real-time dashboards and alerts? Use the activity webhook + database storage.
Need both summary + deep analysis? Combine: webhook for events, scheduled pulls for snapshots.
Worried about deliverability? Track disconnections by sender and domain, and alert on spikes.