Type a search term - or paste a Meetup find URL - and get the event listings back as rows: name, description, start and end time, venue and coordinates, RSVP tallies, topics, and the full profile of the group hosting it. One row per event, across 125 columns, which makes this the widest export on the platform.
You do not have to find the events first. Type what you are looking for and the job returns the listings, each one carrying the group that runs it.
One row per event, each tagged with the query it came from - so a run across a dozen search terms still reconciles back to your input list.
The input is a plain search term - the same thing you would type into Meetup itself - or a find URL if you have already narrowed it down. One line becomes a list of events rather than a single page you had to locate first, and the limit per query decides how far down that list the job goes.
More than half of these columns describe the group running the event, not the event: its name, its urlname and link, where it is based, its timezone, its topic category and topics, its join mode, its member count and its photo. A group's block repeats on every event that group hosts, so one pull answers both what is on and who keeps putting it on.
Start and end times arrive as full ISO-8601 timestamps carrying the event's own UTC offset, with the IANA timezone name in its own column, and the venue block carries latitude and longitude as decimal degrees. That is enough to drop the output straight onto a map or into a calendar without parsing anything by hand.
Each row is one event as Meetup publishes it, with the hosting group's profile denormalised onto the end of it.
The fields are read from the structured data each listing publishes rather than from the page layout, which is what keeps the shape identical across a whole result set. It also explains the width: Meetup's own event record is deeply nested, and the export flattens that nesting into columns, so a block like the venue or the featured photo becomes several columns sharing a prefix. A handful of columns are the raw nesting itself, left in the cell as JSON, because flattening a list of hosts or topics into fixed columns would have to guess how many there are. The dictionary below names all 125 in export order and says which are which - read the note under it before you write a parser.
The export's header row, in order, confirmed against the platform's published column list. Where a nested block flattens into several columns sharing a prefix, the family is listed once and its members are named in the description.
**Saturday** and its own line breaks - render or strip it deliberately rather than assuming plain text.event_group_name. If you want the humans running the event, they are in event_hosts._typename appear through the export for the same reason - they label the block they sit in rather than carry data about the event.event_id.PHYSICAL is one. Worth pairing with the venue columns rather than trusting on its own; see the note on those._typename, _id, _source and _base_url. _source is a direct https link to the full-size image; _base_url is a fixed CDN prefix, the same on every row.2026-07-18T17:30:00-07:00 is the shape. No conversion needed to sort it correctly across regions._typename, _id, _name, _address, _city, _state, _country, _lat and _lng. Coordinates are decimal degrees. Three things to plan for: the block fills or blanks as a whole; it is not filled on every row, including some the type column calls physical, so an event type is not a promise of an address; and the country code casing is inconsistent - lower-case and upper-case forms of the same code both appear, so normalise before you group by it. _state came filled for US venues and blank for the ones outside it.event_series_typename and event_series_description._typename and _total_count. The tally only - this export carries no attendee identities.event_waiting, further down the export, carried the same number as _total_count on every row we have._typename, and _edges which stays in the cell as a JSON array of topic objects with their own ids and names. Parse it as JSON; do not split it on commas._typename, _rsvp_open_time and _rsvp_close_time.event_organizer is often mistaken for.event_network_event_typename, _rsvp_count and _group_count.event_speaker_details_typename, _name, _description, _photo, _social_networks, _photo_typename, _photo_id and _photo_base_url.event_social_proof_insights_typename, _is_trending_event, _total_interested_users and _interested_users_sample. Use the flattened ones unless you need the sample.event_women_friendly_info_typename and _source through the attendance-percentage and sample-avatar fields to the _female_host_* group._typename, _id, _name, _urlname, _link, _is_private, _join_mode, _status, _timezone, _country, _state and _city; its _topic_category_* family and its _topics JSON array; _stats_member_counts_all for the group's size; _needs_photo, _needs_questions, _questions, _dues_settings, _featured_event, _sponsors_*, _group_photo_*, _pro_network_* and _is_in_cumulative_impact_treatment. _link is meetup.com plus the urlname, so the urlname is the group's stable key. This whole block repeats on every event the group hosts - deduplicate on _id before you count groups.America/Los_Angeles - the companion to the offsets in the timestamp columns. It matched the group's timezone on every row we have.event_waiting_count_* above.event_fee_settings.Two habits will save you most of the work here. The first is to treat a row as two records: an event, and the group hosting it. Everything prefixed event_group_ describes the group and repeats on every event that group runs, so deduplicate on event_group_id before you count anything about groups, and on event_id before you count events. The second is to know which cells hold JSON rather than a value - event_hosts, event_topics_edges, event_group_topics, event_group_questions, event_fee_settings, event_group_dues_settings and the interested-users sample all keep Meetup's own nested structure in the cell, because the number of hosts or topics is not fixed and fixed columns cannot hold it. Parse those as JSON; splitting them on commas will not work. Beyond that: event_organizer is the group's name and not a person's, the venue block can be blank as a whole even where the type column says physical, and country codes arrive in mixed case. query is the one column the scraper writes itself, so it is on every row regardless of what the listing published. Everything else is exactly as complete as the listing was - run one search term on the free tier and look at the first rows before you build against it.
A list of search terms and a limit. The input takes what you would type into Meetup itself, and the limit is what decides the size and the cost of a run.
A few examples of how teams use community event data to answer a question they actually have.
Search the topics you care about, then collapse the results by group rather than by event. The member count, the topic category, the join mode and the number of events a group appears on all come back in the same pull, which is enough to rank a long list of communities without visiting any of them.
Because the venue block carries latitude and longitude and the timestamps carry their own offsets, a search for a term across a region drops straight onto a map or into a calendar. Keep the listing link and the group link on the row and every pin still traces back to the page it came from.
The RSVP tallies, the waiting list and the interest figures are true of the moment the row was collected, which makes them a snapshot rather than a fact. Stamp each download with its date and re-run on a schedule, and the difference between the pulls is the signal you were actually after.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.
Every new account, one-time. No credit card required. Per-query limits, file upload and every export format included.
Roughly $2 per 1,000 events. The pre-flight estimator shows the row count and credit cost before a run starts - no surprise bills, no compute units to translate.
Volume pricing, dedicated workers and an SLA for continuous monitoring or very large event pulls. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.Events as Google's own results panel lists them, which draws on ticketing sites and venue pages rather than on community groups. The obvious second pass when you want an event calendar that is not limited to one platform.
The venues themselves - contact details, opening hours and ratings for the places these events are held in. Join the two on the venue name and city and an event list becomes a venue list with it.
Short answer: yes for the public listings - and this export carries no attendee identities.
The fields collected here are the ones an event page publishes in the structured data on its own public listing, for search engines and calendar tools to read. The title, the time, the venue, the topics and the group behind it are shown to anyone who opens the page, signed in or not. Collecting publicly published listings is long-established practice, and nothing here touches a login or an account.
On personal data, the boundary is worth stating precisely rather than claiming there is none. RSVP figures are tallies - a count of how many are going and how many are waiting - and the attendee list behind them is not in this schema. What the export does carry is public-facing organiser information: the hosting group's own name, and inside the hosts field the member names and ids that Meetup shows publicly on the listing. Those are people, so treat that column as personal data and handle it under the rules that apply to you.
Meetup's own terms restrict automated access, so this is a terms question as well as a legal one - if you organise on the platform or have a commercial relationship with it, check them. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
500 one-time free rows on every new account - no expiry. After that it is $0.002 per row, pay-as-you-go - no card on file until you say so.
Livescraper's Meetup Scraper turns search terms into an event table. You type the terms one per line - or paste Meetup find URLs, or upload them as a CSV, XLSX, TXT or Parquet file - cap the rows per query, and download the results as a clean CSV, Excel or JSON file. Requests go out through the shared proxy pool rather than your own address, and there is no sorting control to configure: queries, an optional file and a limit are the whole form.
Each row is one event: its name and description, its start and end time as ISO-8601 timestamps with the event's own UTC offset, its venue with address and coordinates, its topics, its photos, its ticket cap and RSVP rules, and how many people have said they are going or are waiting. Alongside all of that sits the profile of the group hosting it - name, urlname and link, city and timezone, topic category and topics, join mode and member count - which is why a row is really two records and why the export runs to 125 columns.
Two things are worth knowing before you build against it. The organiser column holds the hosting group's name rather than a person's; the people are in the hosts field, which keeps Meetup's own nested structure in the cell as JSON, as do the topics, the group questions and the fee settings. And the venue block fills or blanks as a whole, including on some events the type column calls physical, so an event type is not a promise of an address. Country codes also arrive in mixed case, so normalise them before grouping.
The fields are read from the structured data each listing publishes, which keeps the shape identical across a whole result set and also bounds it: a field a listing does not publish is not there to collect. Run one search term on the free tier and look at the first rows before you write a parser. Your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.