Entitlements by plan

The API enforces the same plan as the app: a key sees exactly what a member of its organization sees. Entitlements are resolved from the organization’s subscription (or a custom Enterprise agreement) and apply to every key of the organization at once; a plan change takes effect on the next request, and open streams reconnect with close code 4409 to pick it up.

Entitlement	Core	Pro	Elite	Enterprise
Market data
Ticketmaster primary and TM resale	Included	Included	Included	Included
Secondary marketplaces	—	Included	Included	Included
Sales history	24 h	Unlimited	Unlimited	Unlimited
Chart history	30 days	Unlimited	Unlimited	Unlimited
Ended events	—	—	Included	Included
% change filters	—	—	Included	Included
Seat-map overlays	Availability	Prices and availability	Prices and availability	Prices and availability
Workflow
Compare events side by side	4	4	8	8
Lists	5	25	100	Unlimited
Events per list	100	500	2,000	Unlimited
Alert rules	25	100	Unlimited	Unlimited
Export rows	—	1,000	Unlimited	Unlimited
API
REST API and stream	—	Included	Included	Included
Requests per minute	—	60	300	1,200
Requests per day	—	50,000	500,000	5,000,000
Stream connections	—	1	5	20
Subscriptions per connection	—	50	500	2,000
Sales and on-sale firehose	—	—	Included	Included
Webhooks	—	—	Included	Included

Prices and trials are on the pricing page. An organization without an active plan can sign in and browse the catalog, but has no API access.

How limits apply

Gated features answer 402

A request for something the plan doesn’t include answers 402 plan-required, naming the plan that allows it. Examples:

• Metrics, series, sales, inventory changes, movers and compare need market data (every paid plan).
• minChg24h / maxChg24h on GET /v1/events need Elite (percent_change_filters).
• Market reads for an event that started more than 24 hours ago need Elite (ended_events).
• Creating a list, an alert rule or a list item beyond the plan’s count answers 402 with limit set to that count.
• Alert rules are checked against the current plan whenever they are used, not only when written. After a downgrade or a lapsed plan, rules the plan no longer allows (their market scope or feature, or enabled rules past its count, counted oldest first) stop firing, and POST /v1/alerts/rules/{id}/test answers 402 for them. They resume once a plan allows them again.
• Creating a webhook endpoint needs Elite (webhooks); exports need Pro (csv_export).

History windows clamp

Sales history and chart history are windows back from now. A read that reaches further back than your window is clamped to it rather than refused:

• GET /v1/events/{id}/series and GET /v1/compare/series start no earlier than the plan’s chart window. A range entirely outside it answers 402 series_history.
• GET /v1/events/{id}/sales and GET /v1/sales/feed only return sales inside the plan’s sales window.
• Test firings of activity rules (POST /v1/alerts/rules/{id}/test) list only changes inside the sales window, and none of events the plan may not read as ended.
• On the stream, since replays at most as far back as the sales window; older gaps answer resync.

Map overlays

On plans without map prices, GET /v1/events/{id}/map/overlay returns availability only: open seats per section and per seat, without price levels.

API access

API keys need Pro or higher. Request quotas, stream connections and subscriptions are listed above and explained in rate limits.

On the stream:

• The sales and onsales firehose topics need Elite (firehose); subscribing on Pro answers an in-band forbidden_topic error.
• Market topics (event.{id}.kpis, event.{id}.sales, event.{id}.primary) need market data.
• Messages are filtered to what the plan may see: sales of markets outside the plan are dropped, and KPI payloads only carry the plan’s markets.