Venue Marketplace Addon Backend

Related documentation: Addon Modules Backend · Venue Module Backend · Promoters Module Backend

Status

The venue_marketplace addon exists in the taxonomy, but a dedicated published backend contract is still deferred.

Expected role

This addon is intended to support promoter-to-venue booking/commercial flow.

That likely means:

• promoter discovery of venues
• booking initiation between promoter and venue sides
• cross-persona marketplace-style flows

Current practical state

Promoter marketplace browse and detail are wired through Backend-Kisum-Promoters (/api/venues/*) into Backend-Kisum-Venues:

• Browse — GET /internal/admin/venues (+ /sleeping) returns marketplace cards; list rows may include company_id for operator-scoped downstream reads but links use venue id only.
• Profile (no operator org) — GET /internal/admin/venues/:venueId via Promoters GET /api/venues/marketplace/venues/:id loads marketplace detail by canonical venue id.
• Operator-scoped detail — GET /internal/venues/:id with x-org = operator company_id (used for tenant-scoped reads when operator org is already known).
• Spaces / availability — GET /api/v1/spaces and GET /api/v1/availability proxied with operator org scope (resolved on detail page from admin profile company_id, or optional ?op= override). Operator-scoped venueId must be the tenant Postgres UUID (venues.id) from the admin profile — not the catalog numeric id in the marketplace URL. Availability is per space; Promoters marketplace detail shows a space selector and loads blocks with spaceId.
• Book — POST /api/v1/bookings from promoter with marketCompanyId = buyer x-org.

Browser UX lives in Frontend-Kisum-Promoters at /venues/marketplace and /venues/marketplace/:id.

Legacy paths still also represented through:

• the Promoters backend (Mongo venue master — deprecated for new flows)
• the Venue backend
• future module/backend work that has not yet been split out into a dedicated venue_marketplace backend contract