Catalog discovery
DashQ catalogs are runtime contracts. They prevent host applications from copying a widget registry that can become stale or expose a surface unavailable to the current session.
Discovery sequence
- Create scope with
POST /api/v1/widgets/session. - Read dashboards with
GET /api/v1/dashboards/catalog. - Read widgets with
GET /api/v1/widgets/catalog. - Render only catalog-approved choices.
- Request data with
POST /api/v1/widgets/{widget_id}/data.
Catalog and data calls use X-Widget-Session-Token. The session's widgetIds claim limits both discovery and execution.
Dashboard catalog
| Dashboard ID | Surface |
|---|---|
portfolio_foundation_v1 | Portfolio Performance |
lead_to_lease_foundation_v1 | Lead-to-Lease |
tour_foundation_v1 | Tour Performance |
application_foundation_v1 | Application Operations |
marketing_foundation_v1 | Marketing / Acquisition |
communication_foundation_v1 | Communication Performance |
Manifest fields describe:
- title, target view, and intended audience
- sections and layout order
- included and pending widget modules
- widget presentation metadata
- dashboard filter capabilities
Use GET /api/embed-dashboard-catalog only for general embed discovery. Use the session-scoped catalog when the returned choices must reflect an explicit widget subset.
Widget catalog
The current registry contains 58 widgets across:
- lead-to-lease funnels and journey details
- portfolio inventory, occupancy, risk, availability, units, and maps
- marketing sources, UTM coverage, attribution, and source quality
- applications, processing time, stage movement, loss reasons, and demographics
- tours, scheduling, outcomes, unit type, property, and representative performance
- email/text/voice AI outcomes and handoffs
- communication channels, calls, first response, and representative usage
Each entry provides the widget's id, title, description, kind, semantic model, required fields, allowed filters, and allowed metrics. Compatible manifests can add presentation metadata.
Filters
Common filters are dates, buildings, limit, and offset. Optional families add building-property IDs, representatives, unit types, stage, source, or lease attribution mode.
Read the catalog before building controls. Hide unsupported controls and reject values outside both the catalog and the user's server-side entitlements.
Definitions and rendering
The catalog explains what can be requested; the Data Dictionary explains what the returned fields mean. Use the dictionary for formula, SQL logic, grain, keys, nullability, cadence, and lineage rather than duplicating definitions in frontend code.
See Data APIs for the backend flow and the API reference for response behavior.