# Ticketmaster Radar — Presale Codes, Alerts & On-Sale (`bovi/ticketmaster-radar`) Actor

**Stateful change-feed for Ticketmaster events** — NOT a one-shot dump. Tracks: (1) **Presale & on-sale calendar** — named windows + ISO times from presaleDates\[] (zero incumbents ship this).

- **URL**: https://apify.com/bovi/ticketmaster-radar.md
- **Developed by:** [Vitalii Bondarev](https://apify.com/bovi) (community)
- **Categories:** Automation, Marketing
- **Features:** Limited permissions
- **Stats:** 4 total users, 0 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $4.75 / 1,000 on-sale / presale alerts

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## Ticketmaster On-Sale & Presale Radar

**The only Ticketmaster actor that ships a stateful change-feed** — not a one-shot dump. The Radar tracks three data types that zero incumbents ship, rebuilt every run by diffing the current payload against the previous run's state stored in Apify KV.

### What Makes This Actor Different

Every other Ticketmaster actor on the Apify Store is a one-shot metadata dump. They scrape and return the same static fields each run. The Radar is designed for **scheduled monitoring** — you set it to run hourly or daily, and it only emits events that actually changed. No noise, no duplicate data, no manual diffing.

| Feature | This actor | easyapi/ticketmaster-events-scraper | parseforge/ticketmaster-scraper |
|---|:---:|:---:|:---:|
| Presale calendar (named windows + ISO times) | ✓ | ✗ | ✗ |
| On-sale date tracking | ✓ | partial | partial |
| Change-detection between runs | ✓ | ✗ | ✗ |
| Resale window detection | ✓ | ✗ | ✗ |
| Price delta (Discovery API) | optional | ✗ | partial |
| KV-backed stateful store | ✓ | ✗ | ✗ |
| No advanced-protection dependency | ✓ | ✓ | ✓ |
| Price | $5/1000 | $4.99/1000 | unknown |

### Three Confirmed Data Types

#### 1. Presale & On-Sale Calendar

The actor extracts `presaleDates[]` from Ticketmaster's open search payload — named windows with ISO start and end times. For example, a Taylor Swift show might return:

- `"Amex Presale Tickets®"` — 2025-01-07T10:00:00Z to 2025-01-09T23:59:00Z
- `"Onsale To General Public"` — 2025-01-10T10:00:00Z onwards
- `"Resale"` — separate resale window

Live-verified on 20/20 Olivia Rodrigo events in the pass-3 probe (2026-06-04). **Zero incumbents ship this data.** Resellers and event analysts plan their purchase timing around exactly this data.

#### 2. Availability Change-Detection

Re-polls `/search` on every scheduled run and diffs:

- `soldOut` — event went sold out
- `limitedAvailability` — limited tickets remaining
- `ticketingStatus` — changes between `PRESALE` / `ON_SALE` / `CANCELLED`
- `eventChangeStatus` — event rescheduled, cancelled, postponed

Emits only the events where something changed (in `delta` mode). The `changed_fields` array in every record tells you exactly what flipped. The `change_type` field gives a single human-readable label: `sold_out_change`, `availability_change`, `status_change`, `presale_calendar_change`, `price_change`, or `new_event`.

#### 3. Price Delta (Optional)

When you supply a free Ticketmaster Discovery API key (available at developer.ticketmaster.com), the actor enriches each event with `priceRanges` (min/max, currency) and tracks price changes between runs. Without the key, the actor still extracts price ranges that appear in the search payload — coverage is lower but setup is zero.

### How to Use

#### Basic presale monitor (no API key required)

```json
{
  "queries": ["Taylor Swift", "Coldplay"],
  "maxEventsPerQuery": 100,
  "stateMode": "delta"
}
```

Schedule this run to repeat every 6–12 hours. Only new and changed events will appear in the dataset.

#### Presale-only filter

```json
{
  "queries": ["Beyonce", "Drake"],
  "stateMode": "presale",
  "maxEventsPerQuery": 200
}
```

Returns only events that have presale calendar data — ideal for resellers who want to plan presale purchases.

#### Full export with price tracking

```json
{
  "queries": ["EDC Las Vegas 2025"],
  "stateMode": "full",
  "discoveryApiKey": "YOUR_FREE_KEY_HERE",
  "maxEventsPerQuery": 400
}
```

### Output Fields

| Field | Description |
|---|---|
| `id` | Ticketmaster event ID |
| `name` | Event name |
| `event_date` | Event date (YYYY-MM-DD) |
| `onsale_date` | On-sale date |
| `presale_dates` | Array of `{name, start, end}` presale windows |
| `presale_count` | Number of presale windows |
| `has_presale` | True if any presale window exists |
| `has_general_onsale` | True if a "general public" onsale window exists |
| `has_resale_window` | True if a resale window exists |
| `sold_out` | Boolean — is the event sold out? |
| `limited_availability` | Boolean — limited tickets remaining? |
| `ticketing_status` | ON_SALE / PRESALE / CANCELLED / etc. |
| `event_change_status` | Rescheduled, postponed, cancelled signal |
| `price_min` | Minimum ticket price |
| `price_max` | Maximum ticket price |
| `price_currency` | Currency code |
| `segment` / `genre` / `subgenre` | Event classification |
| `venue_name` / `venue_city` / `venue_state` | Venue details |
| `changed_fields` | List of fields that changed since last run |
| `change_type` | Single label: `new_event`, `sold_out_change`, etc. |
| `is_new` | True if first time this event was seen |
| `url` | Ticketmaster event URL |
| `scraped_at` | ISO timestamp of this run |

### Input Parameters

| Parameter | Type | Default | Description |
|---|---|---|---|
| `queries` | string\[] | required | Search terms to monitor |
| `maxEventsPerQuery` | integer | 100 | Max events to fetch per query |
| `stateMode` | `delta`/`full`/`presale` | `delta` | What to emit |
| `discoveryApiKey` | string | — | Ticketmaster Discovery API key (optional) |
| `proxyConfiguration` | object | — | Apify proxy config (RESIDENTIAL recommended) |

### Pricing — Pay Per Changed Event

**$5.00 per 1,000 records** (PPE — pay per result). In `delta` mode you only pay for events that actually changed or are new — not for scanning 100 events to find 3 changed ones. The stateful design means a reseller monitoring 50 artists pays almost nothing on quiet days and only pays when presales open or availability shifts.

### Access Approach

Uses the robots-permitted HTML `/search` path only. Confirmed 200 from Apify datacenter IPs with 8× rapid sequential requests, no advanced-protection challenge triggered (pass-3 live probe, 2026-06-04). Apify RESIDENTIAL proxy is recommended for high-frequency scheduled runs to avoid shared-DC-IP rate-limits on Fastly CDN.

The protection-walled ISMDS tier (per-seat live inventory) is intentionally excluded — it is robots-Disallowed and requires a browser-minted access token. This actor does not promise per-seat data.

### Use with AI Agents (MCP)

Callable as a tool from AI agents via Apify MCP:

```json
{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.apify.com/?tools=bovi/ticketmaster-radar",
        "--header",
        "Authorization: Bearer <YOUR_APIFY_TOKEN>"
      ]
    }
  }
}
```

***

*Not affiliated with Ticketmaster or Live Nation. Uses the robots-permitted HTML search surface.*

### Integrations

Built for ticket resellers and event-industry analysts tracking presale windows, on-sale dates, and price deltas over time — the JSON/dataset output drops into the tools you already run, no glue code:

- **n8n / Make / Zapier** — trigger a run or pipe every new dataset item into 500+ apps (Google Sheets, Airtable, Slack, HubSpot, your database) with no code: [n8n](https://docs.apify.com/platform/integrations/n8n), [Make](https://docs.apify.com/platform/integrations/make), [Zapier](https://docs.apify.com/platform/integrations/zapier).
- **Webhooks** — fire your own endpoint the moment a run finishes, to push results straight into your pipeline ([docs](https://docs.apify.com/platform/integrations/webhooks)).
- **MCP server** — expose this actor as a tool to Claude, Cursor, or any [MCP client](https://mcp.apify.com) so an AI agent can pull this data mid-conversation ([guide](https://blog.apify.com/how-to-use-mcp/)).
- **API & SDKs** — fetch the dataset as JSON, CSV, or Excel through the Apify REST API or the Python / JS SDKs.

See all [Apify integrations](https://apify.com/integrations).

### More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

- [Sofascore Live Events](https://apify.com/bovi/sofascore-live-events)

Chain any of them together from the **Integrations** tab (the *Run succeeded* trigger) to build a multi-step workflow — one actor's output feeds the next.

### Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as `USAGE_STATS` in your own Apify key-value store, so you can see the exact record created for your run.

Set `disableUsageStats` to `true` in the input to opt out. Nothing is sent then; your `USAGE_STATS` record only says that statistics were disabled.

Only these fields are recorded:

- schema version, Actor name and build number;
- UTC start and finish hour (not a precise timestamp);
- run duration, number of results and time to the first result, each as a coarse range;
- whether the result was empty, the end status, and an error type from a fixed list;
- memory setting and counts of charged events;
- names of the input fields you set, never their values;
- the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

#### Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same `disableUsageStats: true` input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

#### Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

- the result limit you asked for (a range, when the input has one) and what share of it was delivered;
- results delivered per input item you listed (a range);
- output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
- how the run was started (console, API, schedule, webhook, another Actor);
- how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
- if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
- a short code made from the names of the input fields you set, never their values.

#### Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and `disableUsageStats: true` turns it off.

# Actor input Schema

## `queries` (type: `array`):

List of search terms to monitor on Ticketmaster. Each item is a free-text query sent to www.ticketmaster.com/search. Examples: 'Taylor Swift', 'Coldplay NYC', 'EDC Las Vegas 2025'. Add multiple queries to monitor several artists or events in one run. Schedule this actor to re-run hourly or daily to detect changes.

## `maxEventsPerQuery` (type: `integer`):

Maximum number of events to fetch and track per search query. Each page returns ~20 events. Higher values increase coverage but cost more compute. Default 100 covers 5 pages — enough for most artist tours. Increase to 400+ for broad genre/city monitoring.

## `stateMode` (type: `string`):

Controls which events are emitted to the dataset and charged. 'delta' (default, recommended): only NEW and CHANGED events since the last run — ideal for scheduled monitors, minimal noise. 'full': all events on every run — useful for first-time bulk export or auditing. 'presale': only events that have presale/on-sale calendar data — useful for resellers who care specifically about presale windows.

## `discoveryApiKey` (type: `string`):

Optional: your Ticketmaster Discovery v2 API key (free at developer.ticketmaster.com — 5,000 API calls/day default). When provided, the actor enriches each event with priceRanges (min/max price, currency) from the official Discovery API, enabling price-delta tracking between runs. Leave empty to use the price data already present in the search payload (less reliable but zero setup).

## `proxyConfiguration` (type: `object`):

Apify proxy configuration. Recommended: use Apify RESIDENTIAL proxy to avoid shared-datacenter IP rate-limits on Ticketmaster's Fastly CDN. The open /search path does not require residential for basic operation, but a residential pool provides headroom for high-frequency scheduled runs. If left empty, the actor uses direct (no proxy) — which works fine for infrequent runs.

## `disableUsageStats` (type: `boolean`):

See the README Usage statistics section for details.

## Actor input object example

```json
{
  "queries": [
    "Taylor Swift",
    "Olivia Rodrigo"
  ],
  "maxEventsPerQuery": 100,
  "stateMode": "delta",
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": [
      "RESIDENTIAL"
    ]
  },
  "disableUsageStats": false
}
```

# Actor output Schema

## `results` (type: `string`):

Dataset containing Ticketmaster Radar records (change_type, name, event_date, onsale_date, ticketing_status, sold_out, price_min, price_max, venue_name, venue_city, url, scraped_at).

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "queries": [
        "Taylor Swift",
        "Olivia Rodrigo"
    ],
    "maxEventsPerQuery": 100,
    "stateMode": "delta",
    "proxyConfiguration": {
        "useApifyProxy": true,
        "apifyProxyGroups": [
            "RESIDENTIAL"
        ]
    }
};

// Run the Actor and wait for it to finish
const run = await client.actor("bovi/ticketmaster-radar").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "queries": [
        "Taylor Swift",
        "Olivia Rodrigo",
    ],
    "maxEventsPerQuery": 100,
    "stateMode": "delta",
    "proxyConfiguration": {
        "useApifyProxy": True,
        "apifyProxyGroups": ["RESIDENTIAL"],
    },
}

# Run the Actor and wait for it to finish
run = client.actor("bovi/ticketmaster-radar").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "queries": [
    "Taylor Swift",
    "Olivia Rodrigo"
  ],
  "maxEventsPerQuery": 100,
  "stateMode": "delta",
  "proxyConfiguration": {
    "useApifyProxy": true,
    "apifyProxyGroups": [
      "RESIDENTIAL"
    ]
  }
}' |
apify call bovi/ticketmaster-radar --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,bovi/ticketmaster-radar"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/vJ0jkrkdEbU2dfb1E/builds/3DNaxayGggRVG64hh/openapi.json