Ticket Price Drop & Availability Monitor avatar

Ticket Price Drop & Availability Monitor

Pricing

Pay per usage

Go to Apify Store
Ticket Price Drop & Availability Monitor

Ticket Price Drop & Availability Monitor

Monitor Ticketmaster and StubHub events for price drops, new listings, sold-out inventory, back-in-stock tickets, and section-level availability changes.

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Ula Ula

Ula Ula

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

13 days ago

Last modified

Share

Stop refreshing ticket pages. Get structured price-drop, availability, and inventory-change events on a schedule.

This Apify Actor turns public Ticketmaster and StubHub event pages into a persistent ticket-intelligence feed. It remembers the last complete observation, compares each new run with that baseline, and emits auditable change records for automation, alerts, dashboards, and market research.

It is a monitor, not another one-off ticket scraper.

What it detects

  • NEW_LISTING — a section or resale listing appears
  • PRICE_DROP — price decreases by your configured threshold
  • PRICE_INCREASE — price increases by your configured threshold
  • INVENTORY_CHANGED — listing quantity or section inventory changes
  • SOLD_OUT — an offer is absent for the configured number of complete runs
  • BACK_IN_STOCK — a previously sold-out offer returns
  • EVENT_STATUS_CHANGED — event status changes, for example to canceled

Every change contains stable target and offer IDs, the previous value, the current value, detection time, platform, and source URL.

Common use cases

  • Alert fans when tickets get cheaper or return to inventory
  • Track resale inventory for sports, concerts, theater, and festivals
  • Monitor selected sections instead of an entire venue
  • Build Telegram, Slack, email, or webhook notifications
  • Collect ticket market history in a Dataset or external database
  • Compare primary Ticketmaster supply with StubHub resale listings
  • Feed structured ticket changes into Make, Zapier, n8n, or custom code

Quick start

  1. Add one or more public Ticketmaster or StubHub event URLs.
  2. Set a stable monitorId.
  3. Run once in changes mode to create the baseline.
  4. Create an Apify Schedule, usually every 15–60 minutes.
  5. Attach a webhook to receive change records after each run.

Example input:

{
"monitorId": "summer-concerts",
"targets": [
{
"id": "ariana-chicago",
"name": "Ariana Grande — Chicago",
"url": "https://www.ticketmaster.com/ariana-grande-the-eternal-sunshine-tour-chicago-illinois-08-03-2026/event/04006319DDEA2CD5"
},
{
"id": "celine-paris",
"name": "Celine Dion — Paris",
"url": "https://www.stubhub.com/celine-dion-nanterre-tickets-9-19-2026/event/160790802/?quantity=2",
"minQuantity": 2,
"sections": ["Floor", "101"]
}
],
"priceDropThresholdPercent": 5,
"soldOutAfterMissingRuns": 2,
"outputMode": "changes",
"maxOffersPerTarget": 100,
"maxUpstreamChargeUsd": 5
}

Keep the same monitorId, target IDs, filters, and offer limit across scheduled runs. Changing the monitoring scope can legitimately create new or missing-offer events.

Output example

{
"record_type": "change",
"event_type": "PRICE_DROP",
"monitor_id": "summer-concerts",
"target_id": "celine-paris",
"platform": "stubhub",
"ticket_event_id": "160790802",
"offer_id": "sh:160790802:listing:12316339801",
"changed_fields": ["price"],
"before": {
"section": "411",
"row": "54",
"price": 214.76,
"currency": "USD",
"quantity": 2
},
"after": {
"section": "411",
"row": "54",
"price": 189.5,
"currency": "USD",
"quantity": 2
},
"detected_at": "2026-07-14T12:00:00Z",
"source_url": "https://www.stubhub.com/.../event/160790802/"
}

The OUTPUT Key-Value Store record contains a run summary with:

  • succeeded and failed targets
  • offers observed
  • changes by type
  • child Actor run IDs
  • actual upstream cost when available
  • per-target completeness warnings

Output modes

changes

Recommended for scheduled monitoring. The first successful run creates a baseline and hides initial NEW_LISTING records. Later runs emit changes only.

all

Includes NEW_LISTING records from the initial baseline. Use it when the initial inventory is part of your workflow.

all_current

Returns one current snapshot/status record per target and never updates the persistent baseline. This is useful for previews, one-off checks, debugging, and Apify Store health checks. Failed or ambiguous empty observations are reported as unknown, not as sold out.

Filters

  • sections matches case-insensitive section-name fragments.
  • quantity sets a global minimum adjacent ticket quantity.
  • minQuantity overrides quantity for one target.
  • priceDropThresholdPercent ignores smaller price movements.
  • maxOffersPerTarget bounds runtime and upstream spend.

Ticketmaster currently provides section-level minimum prices and inventory counts. StubHub provides listing-level prices, rows, and quantities when the selected upstream exposes them.

Safe stateful monitoring

Ticket pages and upstream scrapers can fail, get blocked, or return a truncated result. Treating every empty response as sold out would create bad alerts.

This Actor therefore:

  • isolates state by a hash of monitorId
  • versions the stored state schema
  • saves after each successful target
  • does not mutate state after failed or capped child runs
  • rejects suspicious inventory collapses
  • requires consecutive complete absences before SOLD_OUT
  • never compares prices in different currencies
  • preserves before and after evidence

An empty upstream Dataset with no explicit event status is ambiguous. It is reported as incomplete and does not erase a healthy baseline.

Schedules and webhooks

For most events:

  • every 60 minutes for long-range tracking
  • every 15–30 minutes during the final week
  • every 5–15 minutes only when freshness justifies the extra upstream cost

Configure a webhook for ACTOR.RUN.SUCCEEDED and fetch Dataset items from the run. A successful run may correctly contain zero change records in changes mode; use the OUTPUT record to distinguish “no changes” from target failures.

API

Python:

from apify_client import ApifyClient
client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor(
"dataforge_labs/event-ticket-price-availability-monitor"
).call(run_input={
"monitorId": "my-monitor",
"targets": [{
"id": "event-1",
"url": "https://www.ticketmaster.com/.../event/04006319DDEA2CD5"
}],
"outputMode": "changes"
})
items = client.dataset(run["defaultDatasetId"]).list_items().items

JavaScript:

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_APIFY_TOKEN' });
const run = await client
.actor('dataforge_labs/event-ticket-price-availability-monitor')
.call({
monitorId: 'my-monitor',
targets: [{
id: 'event-1',
url: 'https://www.stubhub.com/.../event/160790802/'
}],
outputMode: 'changes',
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();

REST:

POST https://api.apify.com/v2/acts/dataforge_labs~event-ticket-price-availability-monitor/runs?token=YOUR_APIFY_TOKEN

Pricing and spend controls

The Actor uses replaceable Apify Store Actors to retrieve ticket data, so users do not need Ticketmaster or StubHub API keys. Your run can include:

  1. this Actor's pay-per-event charges, and
  2. the selected child Actor's usage or pay-per-result charges.

maxUpstreamChargeUsd is a hard child-Actor spend ceiling divided equally across targets. maxOffersPerTarget and schedule frequency are the main cost controls. The run summary reports child run IDs and available cost data.

Default upstreams are selected from paid repeat benchmarks and can be replaced with ticketmasterActorId, stubhubActorId, and the corresponding input override objects.

Limitations

  • Public page structure, bot protection, regional availability, and upstream Actor behavior can change.
  • Ticketmaster section pricing is not seat-level inventory.
  • StubHub listing IDs and availability depend on what the upstream returns.
  • Fees and taxes may not be included in every displayed price.
  • Currency conversion is not performed.
  • A capped result is intentionally not accepted as a new baseline.
  • This Actor does not reserve or buy tickets.
  • CAPTCHA, login, checkout, queue bypass, and auto-purchase are not supported.

Responsible use

Monitor public event pages at a reasonable frequency. Follow applicable terms, laws, and platform policies. Do not use this Actor to evade access controls, interfere with ticket queues, automate checkout, or facilitate abusive resale.

FAQ

Why was my first changes Dataset empty?

The first successful run establishes the baseline. Use all to include initial listings or all_current for a non-mutating snapshot.

Why does a run say unknown instead of sold_out?

The child Actor returned no trustworthy rows and no explicit sold-out status. The monitor protects your baseline instead of creating a false alert.

Can I monitor only two adjacent tickets?

Yes. Set quantity: 2 globally or minQuantity: 2 on one StubHub target.

Can I monitor a specific section?

Yes. Add case-insensitive fragments such as ["Floor", "101"].

Can I use another scraper?

Yes. Override the platform Actor ID and vendor input. The output must still match one of the supported adapter shapes; test it in all_current first.

Does it auto-buy tickets?

No. The product provides ticket intelligence and change events only.