Luma Events Scraper - New Event Monitor for Cities & Calendars
Pricing
from $2.50 / 1,000 event returneds
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
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
15 days ago
Last modified
Categories
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-foundrow. 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 give | What 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. Needscities.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
| Column | Meaning |
|---|---|
name, url, eventId | Event name, its page on luma.com, and Luma's event id |
startAt, endAt, timezone | Start and end (ISO 8601, UTC) and the event's own time zone name |
city, region, country, countryCode | Where the event is, as given by Luma |
address, fullAddress, addressMode | Street 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, locationType | As given by Luma |
calendarName, calendarUrl, calendarId, calendarIsPersonal | The calendar the event belongs to. Events on a personal calendar have calendarIsPersonal: true and usually no calendarUrl |
hosts, hostNames | Host 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, guestListShown | Number 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, priceIsFlexible | Lowest 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, waitlistActive | Availability as Luma reports it (open, waitlist, sold-out). spotsRemaining is null when Luma gives no number |
requiresApproval | true when the host approves each registration |
coverImageUrl | The event's cover image |
foundIn | The lists of this run the event was found in (city, category, calendar) |
change | Monitoring runs only: new-event |
status, scrapedAt | ok 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).
- First run of a list: the events listed now are remembered. No event rows, nothing charged, one
baseline-savedrow per list. - Later runs: only events that were not listed before are returned (
change: "new-event"). - Nothing new: one free
no-new-eventsrow, 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.
resetMonitoringStateforgets 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.