How to build Luma event dashboards in Metabase

Luma is the events platform behind much of the AI and startup meetup scene — calendars, events, guest lists, ticket types, and RSVPs, with a clean public API sitting behind a paid plan. Metabase is where you turn that activity into shared, trustworthy event dashboards. This guide covers two complementary paths: a lightweight API + CLI route that pulls a scoped slice via the Luma Public API and loads a CSV into Metabase with the Metabase CLI, and a durable pipeline route that lands Luma data in a database so you can build dashboards anyone can read.

How do you connect Luma to Metabase?

Most teams combine both routes: quick answers through API exports and CLI uploads first, then recurring event reporting on a warehouse-backed model.

One caveat shapes everything on this page: Luma's public API requires a Luma Plus subscription. Without it there is no programmatic access at all — only manual CSV guest exports from the event page.

What can you analyze from Luma data in Metabase?

These all come from the same core objects — event guests, plus the events and calendars, ticket types, check-ins your sync exposes:

• Registrations by event and calendar
• RSVP-to-attendance conversion from check-in data
• Repeat attendees across the event series
• Ticket mix and paid vs. free registration
• Registration pacing in the days before an event

Which Luma event dashboards should you build in Metabase?

How do you export Luma data and load it with the Metabase CLI?

There is no vendor MCP server for Luma, so pair a scripted export against the Luma Public API with the Metabase CLI. The export gives you a CSV; the CLI's upload command loads it into Metabase and creates a ready-to-query table and model.

Example workflow

• Ask the API for event guests for each event in the calendar, one row per guest with approval status, registered_at, and checked_in_at.
• Export the result as CSV, keeping stable IDs, timestamps, and the category, space, channel, or event keys you group by.
• Run mb upload csv to load it into Metabase as a table and model, then build questions and dashboards on top.

Be honest about the limits

• Scripted API exports are excellent for exploration, not scheduled reporting.
• A CSV upload is a snapshot; refresh it with mb upload replace or move to the pipeline for real history.
• Registration pacing and repeat-attendee views need every past event in the calendar exported once and kept — the API returns current state, not a history of it.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up the Luma Public API export and the Metabase CLI?

# No vendor MCP server exists. Export directly from the API instead:
curl -s "https://public-api.luma.com/v1/event/get-guests?event_api_id=$EVENT_ID" \
  -H "x-luma-api-key: $LUMA_API_KEY" \
  | jq -r '.entries[] | [.guest.api_id, .guest.approval_status,
      .guest.registered_at, .guest.checked_in_at] | @csv' \
  > luma-event-guests.csv

There is no vendor-published Luma MCP server (verified July 2026). Community projects exist, but they are small, independently maintained, and wrap the same public API you can call directly — so this guide leads with a scripted export. Beware a name collision: luma-api-mcp from Luma Labs belongs to Luma AI, the video and image generation company, and has nothing to do with lu.ma events. If Luma ships an official server later, only route 1's export step changes; the warehouse model below stays the same.

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a event-guests export — creates a table AND a model
mb upload csv --file luma-event-guests.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file luma-event-guests.csv

Can you generate a Luma dashboard with AI?

Yes. Use the prompt below with any assistant that can run shell commands (for the API export) and the Metabase CLI. It works end to end: if Luma tables already exist in Metabase it analyzes those; otherwise it pulls scoped, summarized data, loads it with mb upload csv, then builds the dashboard and caveats any metric that needs missing history.

Create a polished Metabase dashboard for Luma event analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help community, marketing, and support leaders understand registrations by event and calendar, RSVP-to-attendance conversion, repeat attendance, and registration pacing from Luma data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for luma tables and
  models). If durable Luma data is already present — a warehouse sync, a
  database replica, or an earlier upload — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export by scripting the Luma Public API:
  event guests, plus events and calendars, ticket types, check-ins.
  Prefer summarized rollups by month, category, space, channel, or event over raw
  message and post bodies. Write each result to a CSV, then load it with the
  Metabase CLI — run "mb upload csv --file <export>.csv" so each upload creates a
  table and a ready-to-query model. Use "mb upload replace <table-id> --file
  <export>.csv" to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available fields, categories,
spaces or channels, events, and date ranges before creating trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Luma — it reads a database or CLI-uploaded tables.
- Every "active member" card must state its window and its action (posted?
  logged in?) in the card title or description. There is no standard definition.
- Deleted and anonymized accounts disappear from the current member list, which
  silently rewrites historical member counts. Prefer daily snapshots over
  recomputing history.
- Attendance is unknowable without check-in data. Exclude events where nobody
  checked anyone in rather than scoring them as 0% attendance.
- A single CSV is a point-in-time snapshot: only build trend cards if there is
  a usable date column or multiple periods have been uploaded.

Dashboard title: Luma Event Overview

Sections:
1. Executive summary: Registrations this period; Attendance rate
   (check-in data only); Approved share; Repeat attendees;
   Events with no check-in data.
2. Registrations: By event and calendar; approval status mix; capacity fill.
3. Attendance: Conversion by event; no-show rate; check-ins in the first hour.
4. Audience: First-time vs. returning guests; guests by events attended.
5. Pacing: Registrations by days before the event; paid vs. free; ticket mix.

Filters: Date range, Category or Space or Channel, Event, Member segment,
Ticket type.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data.

How do you sync Luma data into a database or warehouse?

For dashboards that need history and reliability, land Luma data in a database first, then connect Metabase to that database.

Connector options

• Managed connector or database replica — use a connector when one genuinely covers the objects you need, or replicate the underlying database when you host it yourself.
• Custom pipeline — use the Luma Public API for control over grain, fields, and refresh cadence.
• API + CSV — use this for quick exploration and one-off slices.

Airbyte publishes a lu.ma source, but know its shape before you plan around it: it's a Marketplace (community-supported) connector with just two streams — events and event-guests — and both are full-refresh only, so there is no cheap incremental guest sync. For anything richer, script the public API: keys are issued per calendar (organization-wide keys exist separately), and rate limits run to 200 requests per minute per calendar, 500 per minute per organization.

Notes

• Decide the grain first (one row per post, message, or registration; daily rollups on top) — it drives every trend card.
• Land raw tables first, then build clean Metabase models on top of them.
• Normalize event, calendar, guest, approval-status, registered-at, and checked-in-at fields.

How should you model Luma data in Metabase?

Core tables

Modeling advice

• Build a clean event_registrations model with common columns across forums, community platforms, chat servers, and event tools, so multi-source dashboards don't fork definitions.
• Snapshot member counts daily into a table you own. Deleted and anonymized accounts vanish from the live member list, which changes last quarter's numbers every time you refresh.
• Keep the definition of "active member" — the window and the action — in the model layer, and surface it in card titles. There is no standard.
• Treat attendance as missing, not zero, when no check-in was recorded. Flag those events explicitly so conversion cards can exclude them.
• Hash or drop email addresses at the pipeline boundary and join members across tools on a stable ID wherever you have one.

Which Luma event metrics should you track in Metabase?

What SQL powers Luma event dashboards in Metabase?

These assume a cleaned analytical model in a warehouse (PostgreSQL dialect). Adjust table and column names to match your pipeline — the modeled names above rarely survive a sync unchanged.

-- Approved guests are the denominator; pending and declined are not.
-- Events with no check-ins return NULL, not 0%.
SELECT
  e.name AS event,
  e.starts_at::date AS event_date,
  COUNT(*) FILTER (WHERE r.approval_status = 'approved') AS approved,
  COUNT(r.checked_in_at) AS checked_in,
  CASE
    WHEN COUNT(r.checked_in_at) = 0 THEN NULL
    ELSE ROUND(
      100.0 * COUNT(r.checked_in_at)
      / NULLIF(COUNT(*) FILTER (WHERE r.approval_status = 'approved'), 0), 1
    )
  END AS attendance_pct
FROM community_events e
JOIN event_registrations r ON r.event_id = e.event_id
WHERE e.starts_at < CURRENT_DATE
GROUP BY 1, 2
ORDER BY 2 DESC;

SELECT
  e.name AS event,
  (e.starts_at::date - r.registered_at::date) AS days_before_event,
  COUNT(*) AS registrations
FROM event_registrations r
JOIN community_events e ON e.event_id = r.event_id
WHERE r.registered_at <= e.starts_at
GROUP BY 1, 2
ORDER BY 1, 2 DESC;

WITH attended AS (
  SELECT
    guest_id,
    COUNT(DISTINCT event_id) AS events_attended
  FROM event_registrations
  WHERE checked_in_at IS NOT NULL
  GROUP BY guest_id
)
SELECT
  events_attended,
  COUNT(*) AS guests
FROM attended
GROUP BY events_attended
ORDER BY events_attended;

What are common mistakes when analyzing Luma in Metabase?

Related

Related analytics

Related dashboards

Related integrations

FAQ