Ticketmaster is the ticketing site that gives a plain HTTP client the most for its bandwidth. On 28 September 2026 we fetched ticketmaster.com through residential exits in the United States and the United Kingdom. The home page answers a client that runs no JavaScript with 200 OK, 559,212 bytes and 494 words; rendering it costs 803,145 bytes and 24 seconds for 1,021 words. The concerts category page is better still: 681,189 bytes, 1,893 words and twenty MusicEvent objects in JSON-LD, each with venue, date and availability, before any script runs. That is the surface for price and availability monitoring, and it is the surface the BOTS Act does not touch.
Half of the home page is free without JavaScript
Every guide ranking for Ticketmaster proxies sells the same thing: a static IP that survives the purchase queue. None of them opens the site. We audited ticketmaster.com twice from a United States residential exit, once as a pure HTTP client with no JavaScript and once fully rendered, and then weighed both responses.
| Fetch | Status | Bytes | Words | What survives |
|---|---|---|---|---|
| Home, no JavaScript, US exit | 200 | 559,212 | 494 | Title, description, canonical, h1, JSON-LD WebSite and Organization |
| Home, rendered, US exit | 200 | 803,145 | 1,021 | Event card titles, city picker, promotional rails |
| Home, no JavaScript, UK exit | 200 | 559,212 | 487 | Identical page, h1 "Ticketmaster United States" |
| /discover/concerts, no JavaScript, US exit | 200 | 681,189 | 1,893 | Canonical, BreadcrumbList, 20 MusicEvent objects, 35 event links |
Two things in that table decide the budget. First, the render is useful on the home page: it more than doubles the words, from 494 to 1,021. That makes Ticketmaster one of the minority of sites in our 52-target set where the browser returns more than the raw HTML. Second, it does not matter, because the page you want is not the home page. The concerts category page gives a no-JavaScript client 1,893 words and structured event data for 681,189 bytes, which is less than the rendered home costs for half the content.
One header shapes the polling interval. The home page arrives with cache-control: max-age=30 from an edge cache, so two requests inside the same 30 seconds return the same bytes. A monitor that polls a category page faster than twice a minute is paying for copies.
The category pages carry structured event data in the head
The server-rendered HTML of /discover/concerts embeds twenty MusicEvent objects as JSON-LD. Each one carries the event name, a startDate, a location with a postal address and GPS coordinates, a performer where there is one, and an offers block with availability set to InStock or EventCancelled and a validFrom on-sale timestamp. One of the twenty in our fetch was already marked cancelled, which is exactly the kind of change an availability monitor exists to catch, and it was readable with no browser at all.
The event links are equally cheap. A single CSS extraction on the same response, with no second request, returned 35 event URLs:
{"events": {"selector": "a[href*='/event/']", "attr": "href", "all": true}}
# 35 links, including ticketweb.com and travel.ticketmaster.com partner eventsWhat the JSON-LD does not carry is a price. For that, Ticketmaster publishes the route itself: the Discovery API returns a priceRanges array with minimum and maximum per event, authenticated by an API key, with a default quota of 5,000 calls per day and 5 requests per second, and a deep-paging cap at the 1,000th item. Per-event pages are a different surface: Ticketmaster puts an identity check in front of them for every logged-out visitor, and they are not where public availability lives. Read the category pages for availability and status, and the API for price ranges, and do not budget for event pages at all.
A UK exit gets the same 487 words: the country is in the domain
We ran the identical no-JavaScript audit through a United Kingdom residential exit. The result was the same page: 487 words, the same canonical, the same h1, "Ticketmaster United States". Ticketmaster does not localise ticketmaster.com off the exit IP; each market is a separate domain, and a British visitor is expected to be on ticketmaster.co.uk. The seven-word difference between 494 earlier in the month and 487 today is the promotional rail rotating, not geography.
So the geo rule on this target is the opposite of what it is on bet365 or Facebook. Pin the exit to the country of the domain you are reading, so that a US residential IP reads the .com inventory, and change the domain, not the IP, to read another market. A rotating pool that mixes countries costs nothing in correctness here, but a pool pinned to the wrong country buys you nothing either.
What the BOTS Act covers, and what it does not
The Better Online Ticket Sales Act of 2016, Public Law 114-274, signed on 14 December 2016 and codified at 15 U.S.C. 45c, makes it unlawful under subsection (a)(1)(A):
to circumvent a security measure, access control system, or other technological control or measure on an Internet website or online service that is used by the ticket issuer to enforce posted event ticket purchasing limits or to maintain the integrity of posted online ticket purchasing order rules
Subparagraph (B) adds selling tickets obtained that way. The statute is about purchase limits and purchase order rules. Reading a category page that the server hands to every anonymous visitor circumvents no purchasing limit, and nothing we measured in this post touches a checkout, a queue or a presale code.
Ticketmaster's own Terms of Use are broader than the statute. Section 6, the Marketplace Code of Conduct, prohibits framing, mirroring, scraping or crawling any part of the Marketplace, using bot technology or automated purchasing software, circumventing any security measure, ordering more tickets than allowed for an event, concealing your identity by using multiple Internet Protocol addresses to conduct transactions, and using the Marketplace for any commercial purpose without written authorisation. The terms forbid scraping the Marketplace and any automated purchasing, and nothing in this post helps with queues, ticket limits or presale codes.
robots.txt is 2,546 bytes and draws the same line in technical terms. It disallows the JSON endpoints behind the interface, including /json/search/event/*, /api/ismds/event, /app/availability and /event-queue, plus seating charts and every checkout path. The HTML category pages are not on the list. If your job is availability and price research for events you are entitled to track, the honest shape of it is the public category HTML plus the Discovery API, not the interface's private JSON.
Cost math with real numbers
Prices from our pricing page: residential proxies from $0.80/GB on the Basic line, mobile from $2.30/GB, and the web scraping API from $0.0002 per page, $0.001 with rendering, billed only on success. A gigabyte is counted as 10^9 bytes.
| Job | Bytes per request | Requests per GB | Cost per request at $0.80/GB |
|---|---|---|---|
| Home, no JavaScript | 559,212 | 1,788 | $0.00045 |
| Home, rendered | 803,145 | 1,245 | $0.00064 |
| Concerts category page, no JavaScript | 681,189 | 1,468 | $0.00054 |
| Concerts category page, web scraping API, no render | n/a | n/a | $0.0002 |
Twenty structured events per category fetch works out to about 29,000 events per gigabyte, or $0.027 per thousand events including every byte of interface you did not want. The same fetch on mobile proxies at $2.30/GB costs $0.00157, 2.9 times more, for a surface that never asked about the network. In 20 fetches from two countries we met no rate limit and no challenge on the pages that matter; the identity check sits on event pages, which this workflow does not open. Residential Basic is the right line, and if you are sizing a pool before buying, how much proxy data you need runs the arithmetic the other way round.
StubHub for the same events
The obvious second source for the same concerts is the resale market, and it behaves in the opposite way. StubHub hands a plain HTTP client 226,417 bytes and zero words; rendering its home page costs 3,238,143 bytes and 35 seconds. We measured it the same day, and the comparison is in StubHub proxies: 0 words without a browser. For primary inventory, Ticketmaster is the richer public source by every number in this post; StubHub only enters the picture when the question is resale price, and then only rendered.
The setting that works on Ticketmaster
- Network: residential, Basic line at $0.80/GB. Nothing in twenty fetches scored the network; mobile at $2.30/GB buys nothing measurable here.
- Fetch mode:
engine: tls, plain HTTP. The home page returns 494 words and the concerts category page 1,893 words with 20 MusicEvent objects; the browser adds words on the home page (1,021) but not data, and costs 803,145 bytes and 24 seconds per load. - Country to pin:
country=usfor ticketmaster.com. A UK exit returns the identical 487 words and the h1 "Ticketmaster United States"; markets are domains, not IPs. - When the proxy is not enough: prices are not in the public HTML. Use the Discovery API's
priceRanges(5,000 calls per day per key) for price, and the web scraping API at $0.0002 per page for the category pages when you want parsed JSON instead of bytes. There is no Ticketmaster collector in our catalogue and, given the terms, we are not building one. - Free tier: every account gets $2 of free API usage per month, which is about 10,000 category-page fetches through the API.