Luma Events Scraper - New Event Monitor for Cities & Calendars avatar

Luma Events Scraper - New Event Monitor for Cities & Calendars

Pricing

from $2.50 / 1,000 event returneds

Go to Apify Store
Luma Events Scraper - New Event Monitor for Cities & Calendars

Luma Events Scraper - New Event Monitor for Cities & Calendars

Luma events (lu.ma / luma.com) by city, category or calendar, one row per event: name, link, start and end, venue, hosts, guest count, price, sold-out and approval flags. Monitoring mode remembers what was listed and returns only events that are new since the last run.

Pricing

from $2.50 / 1,000 event returneds

Rating

0.0

(0)

Developer

NeverEmpty

NeverEmpty

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

15 days ago

Last modified

Share

Luma events (lu.ma / luma.com) from city pages, categories and calendars, one row per event: name, event page, start and end time, venue, calendar, hosts, guest count, price, sold-out, spots remaining and whether approval is required.

  • Monitoring mode returns only new events. Run the same input on a schedule: the first run remembers what is listed, every later run returns only the events that were not listed before. A run with nothing new returns one free row that says so.
  • Asked for X, got X. A city, category or calendar that Luma does not have comes back as a not-found row. It is never silently replaced by another list.
  • An event found in several lists is one row, charged once.
  • No login, no cookies, no proxy. Only Luma's public event lists are read, one request at a time.

What you can read

You giveWhat is read
cities: ["sf"]The upcoming events Luma features on that city's page (80 events for San Francisco on 2026-10-05). Luma listed 87 cities on that day: sf, nyc, la, london, paris, berlin, tokyo, seoul, dubai, toronto and so on
cities: ["sf"], categories: ["ai"]The events of that category around that city, a wider list than the city page (AI around San Francisco: more than 300 events on 2026-10-05, including Palo Alto, Menlo Park and San Jose). Categories: ai, tech, crypto, arts, climate, fitness, wellness, food, family, books, games, running
calendars: ["https://lu.ma/your-calendar"]The upcoming events of that calendar (an organizer's page). Its short name or its id (cal-...) also work

Several cities, categories and calendars can be given in one run. Each city, each city and category pair, and each calendar is read as its own list; lists are added together, not narrowed against each other. A category always needs a city, because Luma lists category events around a place.

Input

  • cities - Luma city names as used in the address (sf, nyc, tokyo), a city name (San Francisco) or the lu.ma address. No default: a run reads only what you give.
  • categories - optional Luma categories; read around each city given. Needs cities.
  • calendars - calendar addresses (https://lu.ma/your-calendar), short names or ids (cal-...).
  • maxEvents - upper limit on event rows when monitoring is off (default 200).
  • monitoringMode - return only events that were not listed at earlier runs.
  • resetMonitoringState - forget what monitoring remembers and start again.

What you get

ColumnMeaning
name, url, eventIdEvent name, its page on luma.com, and Luma's event id
startAt, endAt, timezoneStart and end (ISO 8601, UTC) and the event's own time zone name
city, region, country, countryCodeWhere the event is, as given by Luma
address, fullAddress, addressModeStreet address when the host shows it publicly (addressMode: "shown"). Many hosts show the address to guests only ("obfuscated", 38 of 80 on the San Francisco page): then only the city is given and address is null
latitude, longitude, locationTypeAs given by Luma
calendarName, calendarUrl, calendarId, calendarIsPersonalThe calendar the event belongs to. Events on a personal calendar have calendarIsPersonal: true and usually no calendarUrl
hosts, hostNamesHost names as shown on the event page, each with the address of its Luma profile page. No email, phone, social handle or photo is collected
guestCount, guestListShownNumber of guests when the host shows the guest list. When the list is hidden Luma reports 0, which is not a real count, so guestCount is null (48 of 80 on the San Francisco page)
isFree, price, priceMax, currency, priceIsFlexibleLowest ticket price and, when given, the highest, in the event's currency (27 = 27.00 USD; 7500 = 7,500 JPY). null when Luma gives no price
isSoldOut, spotsRemaining, isNearCapacity, registrationAvailability, waitlistActiveAvailability as Luma reports it (open, waitlist, sold-out). spotsRemaining is null when Luma gives no number
requiresApprovaltrue when the host approves each registration
coverImageUrlThe event's cover image
foundInThe lists of this run the event was found in (city, category, calendar)
changeMonitoring runs only: new-event
status, scrapedAtok for an event row; when the run delivered it

A value Luma does not give is null, never an empty string or a made-up 0. The event description, the guest list and ticket types are not read.

Monitoring mode

Turn on monitoringMode and schedule the same input (hourly, daily).

  1. First run of a list: the events listed now are remembered. No event rows, nothing charged, one baseline-saved row per list.
  2. Later runs: only events that were not listed before are returned (change: "new-event").
  3. Nothing new: one free no-new-events row, and one small monitoring check is charged for each list that was read and had nothing new.

Details that matter:

  • What is remembered is kept per list (per city, per city and category, per calendar), so adding a calendar to a scheduled input does not reset the others; the added list starts with its own first run.
  • An event already returned from one list is not returned again when it later shows up in another list of the same run.
  • Monitoring ignores maxEvents: every new event is returned. If the maximum total charge of a run is too small for all of them, the ones that did not fit are not remembered and come in the next run.
  • Luma's lists are ordered by start time, not by when an event was added, so each monitoring run reads the whole list (up to 40 pages of 50 events).
  • If a list could not be read, nothing about it is charged or changed.
  • Do not schedule two runs of the same lists at the same moment: both may return the same new event.
  • resetMonitoringState forgets everything for all lists.

What is charged

  • Event returned: one per event row.
  • Monitoring check: monitoring mode only, one per list that was read and had no new event.
  • Not charged: the first monitoring read of a list, rows that say a list was not found or could not be read, no-events, no-new-events, limit and budget rows. There is no start fee.

Rows that are not events

Every run says what happened. These rows have a status other than ok, a note in plain English, and are free:

not-found (Luma has no such city, category or calendar) · invalid-input · feed-unreadable / feed-blocked (the list could not be read; the HTTP status is in httpStatus) · no-events (Luma lists nothing upcoming there) · baseline-saved · no-new-events · limit-reached · budget-reached · not-read.

Limits

  • With monitoring off, maxEvents (default 200, at most 5,000) limits the rows; the earliest events by start time are returned.
  • One list is read up to 40 pages (2,000 events). One run reads at most 30 lists.
  • Only upcoming events are listed by Luma on these pages. Past events are not read.
  • City pages are Luma's own selection of events for that city, not every event held there. Use a category with the city for a wider list.
  • Category lists are the events Luma places around the city's coordinates; how far "around" reaches is decided by Luma.
  • Requests are sent one at a time with more than a second between them. A run of one city takes a few seconds; a category around a large city can take about a minute.
  • This Actor is not affiliated with Luma.

Thanks for using this Actor

We build these tools for people who run them every day, and we improve them from what users tell us.

  • Missing a field, or need another filter? Tell us in the Issues tab. If the data is there, we add it.
  • Found a bug or a wrong value? Post the run ID in the Issues tab. Wrong data is the thing we fix first.

If this Actor saved you time, a short review helps other people find it.