Discovering Events
How to programmatically discover the availability of an Event and load only what you want to show to the user
Events are one of the core concepts of the platform – within a Project lives a schedule of Events. An Event is a container in which Elements are created and published at specific points in absolute or relative time. Each Event contains metadata which is defined by the developer in the App Spec.
If you're creating an automation script you may wish to make your logic respond to the current situation. For example to detect if there is an existing live event and inject additional content into it.
Read here about:
Introduction to Event Schedule
The Event Schedule of Events is also known as Listings. It contains a list of Events associated with a Project.
Event Schedule / Listings Reference
This is the primary mechanism of how a client app finds out which events it has access to. If an event is not in listings then in general case the client app does not know about such an event's existence.
All events which are "current" or "on demand" are included in listings where "past" and "future" events are included according to their start time and listings settings specified within Project Settings in Studio.
If there is more than one "past" of "future" event starting at exactly the same time then the specified limits are still enforced. This might mean that not all such events are included in the listings. For example, let's suppose we have:
2 past events, started at the same time: past1, past2, where past1 was created before past2
1 current event: current1
2 future events, starting at the same time: future1, future2, where future1 was created before future2.
Suppose also that our listings settings are set to 1 past event and 1 future event.
In this case the listings will include past2, current1, future1 events.
Discover Events by polling the public listings feed
On either front or backend you can discover events via a public feed which is associated with your Project. First, you'll need to obtain the public listings feed URL from Studio, which is unique to your Project. The URL has the following structure:
Where <static host>
is unique to your instance of the Platform (usually studio.monterosa.cloud), <project GUID>
uniquely identifies your Project and <prefix>
is the first two characters of the <project GUID>
.
This URL points to a JSON file hosted by our CDN and designed to be polled by front end applications at scale. However, we recommend your applications poll this file no more than once every 30 seconds. More frequent polls are discouraged as the CDN cache and cache-control headers in the response will prevent you from getting more frequent content updates.
The JSON object returned will contain an events
node, which is an array of Event-specific objects. Each object has the following structure (some fields excluded for simplicity):
Most of the fields are self-explanatory, digest
contains a hash of all the other fields' values, which can be used to detect changes.
The above information is enough for your code to understand when an Event becomes live and to load the web application dynamically.
Backend access to Listings via Control API
You can access the same data as contained within the public feed, but via the backend Control API.
This is a REST API and you can get going by reviewing the dedicated documentation for it here:
Last updated
Was this helpful?