Eventbrite Event Scraper

What is Eventbrite Event Scraper?

Eventbrite Event Scraper gets every event out of an Eventbrite search, including the ones the site will not paginate to. Eventbrite's search tells you it found up to 10,000 events and then serves 49 pages of 20. Ask for page 50 and you get HTTP 200 with an empty list, which an ordinary scraper reads as the end of the data. It finishes, reports success, and hands you 980 events with no hint that anything is missing.

This actor splits the query by date, then by category, until every slice fits under the cap. It runs the slices, deduplicates on event ID, and writes a coverage report at the end saying which slices it drained completely and which it could not. One day in New York: 1,381 events against 824 from straight pagination. The same test in London: 1,998 against 938.

• No proxy and no headless browser. It talks to the same JSON endpoint the search page uses.
• Public listing data only. Organizer personal data is never requested, so it is never in your dataset either.
• It cannot see private, unlisted, or password-protected events. If Eventbrite's public search does not return it, neither does this.

The problem every other Eventbrite scraper has

Eventbrite's search says one thing and does another. Ask it for events in New York and it reports:

"pagination": { "object_count": 10000, "page_count": 49, "page_size": 20 }

It claims 10,000 events, but it will only serve you 49 pages × 20 results = 980 of them. Request page 50, 100 or 500 and you get HTTP 200 with an empty result list: not an error, not a warning. Just nothing.

So a scraper that pages until the results run out stops early, concludes it finished, and hands you under 10% of a large city while reporting a successful run. You have no way to tell the difference between "that's all the events" and "that's all we could reach."

Measured on single days in two cities, 2026-08-29 and 2026-08-30:

City (one day)	Paginate-until-empty	This scraper	Events the naive approach never sees
New York	824	1,381 (+68%)	572
London	938	1,998 (+113%)	1,069

Both runs: zero failed requests, no proxy. And that is a single day in each city: on an unbounded city query the gap is far wider, because the 980-result ceiling applies to the whole query at once.

How this one works

It probes the query first, reads what Eventbrite admits it has, and when the answer exceeds what pagination can serve, it splits the query: by day, then by category: until every slice fits under the cap. Then it collects each slice and deduplicates by event ID.

When a slice still cannot be fully covered, the run tells you so instead of quietly truncating. Every run writes a COVERAGE_REPORT to the key-value store:

{
  "eventsReturned": 1381,
  "declaredByEventbrite": 1078,
  "slicesPlanned": 21,
  "slicesTruncated": 2,
  "estimatedUnreachable": 1578,
  "truncatedSlices": [
    { "slice": "united-states--new-york · performing-arts · 2026-09-11", "declared": 1769, "reachable": 980 }
  ]
}

Honest coverage beats a confident number you cannot verify.

Input

Field	Description
place	Location slug from any Eventbrite search URL: the part after /d/. E.g. united-states--new-york, united-kingdom--london, czech-republic--praha
dateFrom / dateTo	Optional YYYY-MM-DD range. Narrowing it improves coverage in busy cities
maxItems	Hard stop, so run cost stays predictable

Minimal run:

{ "place": "united-states--new-york", "maxItems": 500 }

Output

One row per event:

Field	Example
name	Brooklyn Night Market
startDate / startTime	2026-09-11 / 18:00
venueName / venueAddress	Industry City / 220 36th St, Brooklyn, NY 11232
latitude / longitude	40.6553 / -74.0058
isOnline / isCancelled	false / false
ticketsUrl, imageUrl, tags, summary
sourceCategory / sourceDate	which slice found it: full provenance

Export as JSON, CSV, Excel, or call it from your own code as an API. Every field is described in the dataset schema, so AI agents calling this through MCP know the shape before they run it.

What it does not collect

No organizer names, emails, phone numbers, or social handles. Only the numeric organizerId. Event listings are commercial information; organizer identities are personal data, and this scraper leaves them alone by design. If you need contact enrichment, this is not the tool.

Speed and cost

No headless browser and no residential proxies: event data is served in the page itself. Across the two live tests above: 496 requests, zero failures, no proxy. That is why runs are cheap and why the run success rate stays high.

Typical uses

• Event aggregators and city guides: fill a calendar without missing 90% of the city
• Venue and market research: which venues host what, how often, at what scale
• Sponsorship and lead research: find events matching a category and date window
• Competitive tracking: monitor a category over time by re-running on a schedule
• AI agents: call it as an MCP tool; the output schema is declared, so the agent knows what it gets

FAQ

Does Eventbrite have an official API? Yes, but its public search was retired for third-party use, and what remains is oriented toward managing your own events, not discovering everyone else's. That is why scrapers exist for this.

Why did I get more events than object_count said existed? Eventbrite's per-category counts overlap and its totals are approximate. Deduplication is by event ID, so every row you get is a distinct real event.

Can it cover a whole country or a date range of months? Yes: give it a date range and it will slice day by day. Longer ranges mean more requests, so set maxItems to bound the cost.

Something broke. How fast will it be fixed? Issues are answered within 12 hours. If Eventbrite changes its page structure, the run fails loudly rather than returning partial data silently: you will know immediately, and so will I.