Eventbrite Events Scraper

Scrapes events from Eventbrite by location, with optional keyword, date-range and language filters. HTTP-only (no browser), and every filter it offers was verified to actually work upstream.

What you get

One row per event, plus a SEARCH_SUMMARY row per query and an ERROR row for any query that fails — so every input maps to at least one row.

Each event row carries Eventbrite's own search object verbatim under listing (36 fields), with the most-used ones lifted to the top level:

Field	Example
eventId	1984167730093
eventName	Black & Bronze: A Bronzeville Music Fest
eventUrl	https://www.eventbrite.com/e/...-tickets-1984167730093
startDate / startTime	2026-08-29 / 13:00 (local, with listing.timezone)
isOnlineEvent	false

Inside listing you also get: full_description, summary, tags (including Eventbrite's own category/subcategory labels such as Music / R&B), primary_venue (name, full address, latitude/longitude), end_date, is_cancelled, series_id, tickets_url, language, image (multiple sizes).

Optional detail pass

includeEventDetails: true fetches each event's page and attaches its JSON-LD under eventDetail, adding the three things search rows genuinely lack:

• offers — ticket price, currency, availability
• organizer — organizer name and URL (search only gives a numeric id)
• performer

Costs one extra request per event, so it is off by default.

Input

{
  "locations": ["il--chicago", "united-kingdom--london"],
  "keywords": ["jazz"],
  "startDate": "2026-09-01",
  "endDate": "2026-09-30",
  "includeEventDetails": false,
  "maxItems": 100
}

locations takes Eventbrite location slugs — the part of a search URL after /d/. Both grammars work (united-states--new-york, il--chicago), as does online for online-only events. Non-US markets are fully supported (London, Sydney, Toronto, Berlin, Jakarta all verified live).

The run is the cross product of locations × keywords, each pair getting its own summary row. Leave keywords empty to fetch everything in a location.

Known limits — read these before scaling a crawl

~1,000 events per query, whatever the total says. Eventbrite stops serving rows after page 50 (20/page). This was bisected live: page 50 returned 19 rows, page 51 returned zero, on a query whose own total claimed 5,524. When a query stops for this reason the summary row sets reachableCeilingHit: true. To get more, split the query — more locations, more keywords, or narrower date ranges.

totalResults is an upper bound, not a row count. It is capped at 10,000 for large markets, and when a keyword is used it reports a fixed pool size rather than a match count (a real and a nonsense keyword both reported 6,930 while returning almost entirely different events).

Keyword search is relevance-based, not exact-match. A keyword with no strong matches returns loosely-related events rather than nothing. That is Eventbrite's own search behaviour, documented here rather than papered over.

Location may resolve to a narrower place. indonesia--jakarta is served as indonesia--jakarta-pusat (one district). The summary row reports locationExactMatch: false along with locationResolvedSlug and locationResolvedName so the label always matches the data.

Category filtering is not available. Eventbrite's category browse pages (/b/{location}/{category}/) serve only an 8-event teaser with no working pagination, and the underlying category tag is inert on the deep-paginating search surface (verified). Use keywords instead — and note every row already carries its categories under listing.tags for client-side filtering.

Filters deliberately not offered, because each was measured to be silently ignored (they return unfiltered results under a filtered label): price, cats, dates, online_events_only, page_size, tags.

Date range needs both bounds. startDate without endDate is silently ignored upstream, so the actor refuses that input instead of returning unfiltered events.

Anti-bot / transport

No WAF, no challenge page, no JS gate — 8 TLS profiles across both the search and detail surfaces returned clean 200s, cold, without warmup.

What Eventbrite does enforce is a per-IP request-velocity limit: sustained bursts earn a plain HTTP 429 that persists for ~3–4 minutes and does not clear on TLS-profile rotation. The actor treats 429 as retryable, backs off progressively, and rebuilds its session (drawing a fresh proxy exit IP) on each retry — which is what actually clears it.

Because of this, minRequestInterval is the honest speed control here, not maxConcurrency: once the limit binds, extra parallelism buys nothing. Defaults are deliberately gentle (interval 2s, concurrency 3). Residential proxy is the default and is intentionally not country-pinned, since a rotating pool is precisely the remedy for an IP-scoped limit.

robots.txt

The /d/ search surface and /e/ event pages this actor uses are not disallowed. Eventbrite's robots.txt disallows /directory/, /api/v3/destination/events/, /land-browse-bff and a set of query-string patterns (*?i*, *&i*, *?x*, *&x*, *?calendar*, *&id*, …); every parameter this actor emits (page, q, start_date, end_date, lang) was checked against that list. The internal /api/v3/destination/search/ JSON endpoint was deliberately not used — its sibling paths are explicitly disallowed, and the SSR page carries the same payload anyway.