Google keeps a separate results vertical for events - the panel you get for a query like "events in Berlin this weekend". This service reads that vertical for a list of queries and returns the results as rows, so a calendar you'd otherwise assemble by hand becomes a file.
Worth being precise about what this reads, because "events" invites a bigger assumption than the service makes.
Google's events vertical is a search surface. Ask it what's on in a city this weekend and it returns a ranked list of results - the same mechanism as any other vertical, pointed at event listings instead of web pages. This service submits your queries to that surface and hands back what it returns.
What it is not is a ticketing integration or a licensed events feed. It reads a public results page. Nothing is booked, nothing is purchased, and no venue or ticketing account is involved.
One more thing, stated plainly rather than buried: the published reference for this endpoint documents the request side in full but does not publish a column list for the results. The eight columns in what you get back come from real Livescraper exports instead - and those exports carry the header row without example values, so that section says which columns arrive and stops there.
The same shape as the other search verticals - a list of queries, a locale, and how deep to go.
Pages per query defaults to one page, so a run stays modest unless you deliberately go deeper.
This list is the actual header row of Livescraper event exports, in sheet order. It is not copied from the API reference - that document covers the request side and leaves the result columns unspecified - and it is not borrowed from any other service on this site.
Column names are confirmed; values are not. The seven exports behind this list all came back with the header row and no data rows, so we can tell you exactly which columns arrive but not what a populated cell looks like. Run one query against the one-time 500 free rows to see real values in each column before you build against them.
Three settings shape a run. On this vertical they are not equally important.
Breadth - up to 1,000 queries in one run. Event research is naturally many-queried, because the unit of interest is usually a city, a venue or a genre, and you rarely want just one. A single run can hold a whole territory. Depth - pages per query, defaulting to one. The first page is what a person planning their weekend sees, so it's usually the honest sample; go deeper when you're building an exhaustive calendar rather than a visibility read. Locale - language and country as separate settings, the same pair used on the Google Search Scraper. Every vertical is somewhat localised. This one is about locality: an event is a thing happening in a place, so the country you search from shapes the result set more here than anywhere else in the catalogue. Leaving it at the default and reading the output as global is the mistake to avoid.
A practical consequence: put the place in the query as well as in the settings. "Jazz concerts Lisbon" and "jazz concerts" searched from Portugal are different questions, and the first is almost always the one you meant.
Where an events export earns its keep.
The date you pick decides half your attendance. Pulling what's already on in a city for a given period shows the clashes before you commit - the festival, the match, the conference that will quietly take your audience. Teams run it per candidate weekend and choose the quiet one.
Sweep a genre across a region and the same venues and promoters keep reappearing. That's a partnership list you can act on, built from what's actually being booked rather than from a directory that may be years stale.
Destination sites, hotels and local publishers all need a "what's on" page that isn't six months old. Re-running a fixed set of city queries on a schedule keeps one up to date without a manual trawl through a dozen listings sites every week.
No subscription, no minimum, no per-city licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. All scrapers unlocked - and on this service in particular, the free rows are how you see real values in each column before committing to anything.
Roughly $2 per 1,000 results. With depth defaulting to a single page, a city-by-city sweep costs less than most people assume - the estimator prices the run before it starts.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams keeping event calendars current across many markets. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.Announcements land in news, organisers have websites, venues have listings. Teams tracking what's on rarely watch only one surface.
Events get announced before they get listed. The news vertical filters to the last hour, day, week, month or year - and its seven columns come back populated, so you can see real values before you build.
The organic vertical for the same queries - listings, ads, shopping results and related questions. Where the venue and organiser websites themselves show up, with a documented field set.
Short answer: yes. This reads a public results page, and the thing being read is information published to attract an audience.
An events results page is public. Google shows anyone what's on in a city, signed in or not. Collecting publicly visible results for research and planning is long-established practice, and as long as the data is publicly available and the process doesn't disrupt the site there are no federal laws prohibiting it.
Events sit unusually comfortably here. An event listing exists in order to be found - the organiser published it precisely so people would see it. There's no personal data at the centre of it, no login, no paywall, and nothing is booked or bought on your behalf.
Google's terms restrict automated access, so this remains a terms question. We touch nothing behind a login, 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.
query, title, date, venue, address, link, description and thumbnail. That is the header row of real Livescraper event exports, identical across seven separate runs - not a list from the API reference, which leaves the result columns unspecified. One caveat worth knowing: those seven exports came back with the header row and no data rows, so the column names are confirmed but example values aren't. Run one query on the free 500 rows to see populated cells.Submit your city, venue or genre queries and get Google's events results back as rows. Your first 500 rows are free - and they're the right way to see real values in each column before you plan anything around them.
Google maintains a dedicated events vertical: ask what's on in a city this weekend and you get a ranked list of results rather than ordinary web pages. For anyone whose work depends on knowing what's happening where - event marketers picking a date, promoters mapping a region, destination sites and local publishers keeping a "what's on" page current - that vertical is the most convenient single view of the calendar in existence. Reading it one query at a time in a browser is the bottleneck. The Google Search Events Scraper removes it: submit up to 1,000 queries in a run, set language and country, choose how deep to go per query, and take the results away as CSV, JSON or Excel with each query's results kept distinct.
One thing is worth saying directly on this page, because pipelines get built on assumptions. The published reference for this endpoint documents the request side in full but does not specify the result columns, so the eight-column list on this page does not come from there - it is the header row of real Livescraper event exports, identical across seven separate runs. Nothing on this page is a guess at what an events row "should" contain. The limit of that evidence is worth stating too: those seven exports arrived with the header row and no data rows, so we can name every column and cannot show you a populated one. The recommendation that follows is concrete rather than hand-waving: run a single query against the one-time 500 free rows and open the file. A minute's work and no money shows you real values in each of the eight columns, which is a better foundation than a confident-sounding table on a marketing page.
What the run does control is well defined. Breadth is up to 1,000 queries, which suits event research particularly well, since the natural unit is a city, a venue or a genre and you almost never want only one. Depth is pages per query and defaults to a single page - usually the honest sample, because one page is what a person planning their Saturday actually sees. Locale is language and country as separate settings, and on this vertical it is the setting that matters most: an event is a thing happening in a place, so where you search from shapes the results more than it would for a text query. The practical advice that follows is to name the place in the query as well, since "jazz concerts Lisbon" and a bare "jazz concerts" run from Portugal are not the same question.
Typical workflows fall into three shapes. Scheduling teams pull what's already on across candidate dates and pick the weekend without a clashing festival or fixture. Business development teams sweep a genre across a region and read the recurring venues and promoters as a partnership list built from real bookings. Content and travel teams fix a set of city queries and re-run them on a cadence, treating the difference between exports as their update queue. All three are pointer work - you learn what exists and where to look next, which is exactly what a results page is for. Nothing is booked or purchased, nothing behind a login is touched, and exports auto-delete after 30 days. Start free: your first 500 rows cost nothing and need no credit card.