Lookout is Future Demand’s discovery and insights surface. It tells a partner which events to focus on, what demand looks like today vs the prediction, and what to do about it. If you’re building a partner integration, Lookout typically comes first — your users see the same data they already get in the reference webapp, inside your own UI.

​
The pages you’ll rebuild

PageWhat it showsGuide
DashboardKPI scoreboard + upcoming events panel.Dashboard
Events listFilterable, paginated list of all events with status badges and the demand benchmark.Events list
Event detailFull event view: hero, stats, sales graph, daily revenue, ticket categories, taste clusters.Event detail
Event editorEdit one event’s metadata (title, venue, lineups, …) and optionally trigger a recommendation refresh.Event editor
Bulk event uploadCSV/XLSX bulk import for ingesting many events at once.Bulk event upload
Sales uploadsPer-event manual sales ingest + generic file uploads.Sales uploads
SimulationCreate a synthetic event to probe model behaviour. Optional, feature-flagged.Simulation
1

Auth + Dashboard

Stand up authentication, the partner picker, and the Dashboard. Three API calls. Lets you confirm the end-to-end loop.
2

Events list

Add the paginated, filter-driven list. The same /events/ endpoint powers Wave’s list too — investment compounds.
3

Event detail

The heaviest page in Lookout — ~9 parallel GETs on mount. Build it once, reuse the components in Wave’s campaign detail.
4

Mutations

Flag / archive / pause — the small set of state changes that need the two-step CR API dance.
5

Sales / bulk / simulation

Optional, depending on whether your users ingest their own data.

​
What you do not need to rebuild

  • The platform admin surfaces (/auth/users/csv_export, POST /partners/, …). Internal-only.
  • The “prompt registry” endpoints (POST /prompts/...). Used for internal LLM tuning, not partner integrations.
  • Sentry/Redux/i18n plumbing the reference webapp uses. Use your own.

​
What’s tricky in Lookout

The “calibration data” you need to mirror behaviour exactly:
  • Two API hosts. Most calls hit the main API; EventEditor, Simulation, bulk upload, and the second half of the status-update dance go to the Customer Representation API (cr_api). See CORS & two-host architecture.
  • Benchmark scale auto-detection. The benchmark payload comes back as fractions on some deployments and percentages on others — the reference webapp auto-detects.
  • Repeated query params for arrays. Use ?city=A&city=B, not city[]= or CSV. See Pagination.
  • The formatApiEvent normalisation. The list view flattens benchmark into a different shape than the detail view. Don’t over-normalise.
Each guide flags the specific gotcha relevant to that page.