An event is the unit of analysis and activation across both Lookout and Wave. It can be a concert, a fixture, a fair, a product release — any finite-window thing your audience can buy a ticket or admission to.

​
Event shape (read)

Shortened example. The real /events/ payload has many more fields than shown here (campaign state flags, predicted-sales fields, benchmark sub-objects, etc.). Treat this as illustrative — inspect a live response for the full contract, and don’t assume these are the only fields.
{
  "id":               "evt_abc123",
  "title":            "Concert at Olympiahalle",
  "start_date_time":  "2026-06-12T18:30:00Z",
  "city":             "München",
  "venue_name":       "Olympiahalle",
  "hall_name":        "Main Hall",
  "capacity":         12000,
  "category":         "concert",
  "special_ad_category": null,
  "predicted_sales_share": 0.71,

  "status":          "active",
  "frontend_status": "DEFAULT",
  "campaign_status": "RUNNING",
  "client_campaign_status":          "RUNNING",
  "campaign_optimisation_status":    "ON",
  "ad_campaign_optimisation_status": "ON",
  "campaign_event_series":  ["evt_abc124", "evt_abc125"],

  "benchmark": {
    "prediction": { "value": 0.78, "benchmark": 0.65 }
  }
}
There is no currency field on the event object. Currency is stored at the partner level — read it from GET /partners/ (currency), or, for display, from the user/tenant setting the reference webapp keeps in browser storage (userCurrency).
The list endpoint (GET /events/) wraps these in the standard envelope: 
{ "total": 423, "limit": 50, "page": 1, "pages": 9, "items": [ ... ] }

​
Statuses you’ll deal with

There are several status fields on an event. They are independent and mean different things.
FieldValuesMeaning
statusactive, archived, cancelled, …Backend lifecycle.
frontend_statusDEFAULT, FLAGGED, HIDDEN, CANCELLEDUX state. FLAGGED pins to the top of the list; HIDDEN archives from the user’s view; CANCELLED marks a cancelled event.
campaign_statusRUNNING, OPEN, CLOSED, IGNOREDWave campaign roll-up.
client_campaign_statusRUNNING, PAUSEDThe user’s pause/run toggle for this event’s Wave campaigns.
campaign_optimisation_statusON, OFFWhether Future Demand’s automated optimisation is active.
ad_campaign_optimisation_statusON, OFFSame, but at the per-platform ad-campaign level.
Most UIs only need frontend_status (for the list view) and one of the campaign-status fields (for the action menus). The rest are platform internals.

​
Reads you’ll actually use

PurposeEndpoint
List with filtersGET /events/
Flagged-only listGET /events/flagged/
List of venues (optional filters)GET /events/venues
Single event detailGET /events/{eid}
Tenant-wide statisticsGET /events/statistics
Demand benchmarkGET /events/{eid}/lookout_prediction_benchmark?type=capacity|ticket_count
Demand prediction curveGET /events/{eid}/lookout_prediction?type=capacity|ticket_count
Daily revenue / ticketsGET /daily_revenue_summary/?event_id=&currency=&start_date=&end_date=
Ticket categoriesGET /events/{eid}/tickets
Sibling events in seriesGET /events/{eid}/series
Taste clustersGET /events/{eid}/clusters
Suggested clusters at a budgetGET /events/{eid}/suggested_tcs?budget=&goal=
Default Wave campaign paramsGET /events/{eid}/default_campaigns_parameters
Existing campaignsGET /events/{eid}/campaigns
lookout_prediction_benchmark and lookout_prediction both require a type query param: capacity (percentage mode) or ticket_count (absolute values). These replace the older benchmark / sales-graph paths.

​
Venues filter

GET /events/venues returns the full venue list with no parameters. It also supports optional repeated filters per Swagger — city[] and venue[]: 
GET /events/venues                          # full list
GET /events/venues?city=Berlin&city=Munich  # filtered
Treat the filters as optional, not required.

​
Writes

PurposeEndpoint
Toggle flag / archivePUT /events/{eid}/setup_frontend_status
Pause / resume Wave campaignsPUT /events/{eid}/client_campaign_status?...
Toggle automated optimisationPUT /events/{eid}/campaign_optimisation_status?...
Reset Wave setupPUT /events/{eid}/reset_campaigns_setup
Edit event meta (CR API)[cr_api] PUT /events/{eid}?event_type=...&partner_product=...
Manage event seriesPOST /events/{eid}/series, DELETE /events/{eid}/series
Two-step status updates. Setting frontend_status is a two-call sequence: PUT /events/{eid}/setup_frontend_status (main API) followed by PUT [cr_api] /events/last_updated_on_fe/{eid}. The CR status is CANCELLED only when frontend_status === "CANCELLED"; otherwise it’s RUNNING (including for HIDDEN). See Event detail guide.

​
Sales data

Two ingest paths and a clear endpoint:
PurposeEndpoint
Manual transaction-summary ingestPOST /ingest/transaction_summary
Excel file ingestPOST /ingest/transaction_summary/from_excel?eid={eid} (multipart)
Clear all ingested salesDELETE /daily_revenue_summary?eid={eid}
Bulk sales-edit XLSX (download/upload)GET/POST /daily_revenue_summary/sales_edit_export

​
Event series

A series groups sibling events — multi-date tours, repeat fixtures, weekly recurrences. GET /events/{eid}/series lists members; the available pool for adding new members comes from GET /events/{eid}/available_events_for_series. Mutations: 
POST   /events/{eid}/series?event_series=evt_x&event_series=evt_y
DELETE /events/{eid}/series?event_series=evt_x
Note these mutations send the list as repeated query params, not a JSON body.

​
Lifecycle (typical flow)

ingest (CR API)  ─▶  active           ─▶  campaign_status: OPEN
                       │                       │
                       │  user flags           │  user runs Wave wizard
                       ▼                       ▼
                  FLAGGED              client_campaign_status: RUNNING
                                              │
                                              │  event runtime ends
                                              ▼
                                     campaign_status: CLOSED