Regions pose a unique challenge as it means that, depending on the region the user has selected, different templates, presenters, venues and events can be displayed. All of these entities are regionalized, and regions are managed by administrators (who would flag each of these entities is being associated with one, or all regions).
As far as the API is concerned, regions are fully supported. Each of the endpoints (where relevant) support a region parameter that lets you indicate the region context of your request. For example, region=AU would cause the system to return offers in AUD+GST, and region=UK would cause the system to return offers in GBP+VAT, or perhaps no offers at all if there are none available for the UK region.
With a region-enabled platform your team would need to consider:
- Ensuring the frontend UI has a mechanism for allowing visitors to choose their region and/or autodetecting it. This could be a dropdown list or something else your designers can come up with.
- Ensuring the site has an information structure that can support pages having different content on a per-region basis. This has particular significance for search engine indexing and how you’d want regionalized versions of content exposed.
Our solution is to put the region in the URL such as/au/events/my-event-namewhich is indexed separately to/uk/events/my-event-name. - Ensuring all of your API calls provide region parameters, and cache details on a region-specific basis.