The Hub Region
Every request resolves a hub region, from ahubRegion query parameter or a Hub-Region header, defaulting to UK when neither is present. Every document carries the region it belongs to, and every configuration lookup is scoped by it.
That one value determines which Vivenu account is called, which classes and power levels apply, which shop URL is used and which currency is shown.
Configuration Lives In The Database
Business configuration is not in infrastructure code. It is held as documents in theConfigurations collection, under well known IDs, some global and some per region. They cover the regions themselves and their Vivenu credentials, the class codes and power level tiers, the booking site settings, and the championship definitions.
Why It Is Built This Way
Championships are defined per year, marketing redirects move, and new regions launch. If those lived in CDK, every change would need an engineer and a deployment. Holding them as documents means operators change them through the dashboard and the change takes effect immediately.The Exception
Race level eligibility, which restricts power levels by race type, is hardcoded in the application rather than stored as a document, and has separate tables for the checkout path and the admin path. See Ticket Eligibility.What Reads The Region
Adding A Region
Adding a region is not a deployment. It is a MongoDB migration written by hand, plus configuration in Vivenu. The full procedure, including the Vivenu seller, domains, API key, webhooks and the migration itself, is documented under Setting Up a New Hub.The new region’s HMAC secret has to match on both sides: generated for the region configuration, then base64 encoded into each of the four Vivenu webhooks. A mismatch produces webhooks that return 401 and sales data that never arrives.