Please note, although the widget API can be called directly from a web app, we would strongly recommend proxying it through your own backend, and adding some level of caching. The response itself is highly cacheable. If we notice high levels of traffic for your status page, then in the first instance, we will reach out to you to discuss this. If you have any queries about this, please get in touch.
Response structure
You can see a preview of the full JSON response from within the “Widget API” settings page. It contains three arrays —ongoing_incidents , in_progress_maintenances and scheduled_maintenances , allowing you to distinguish between those three different types of event. Each incident in those arrays will have dates associated with it.
Each incident also has an ID, name, status, the last update message, and several other fields. It also contains affected components. By implementing your own logic, you can use these components to decide (for example) whether to show a banner on a certain page or not. For example, if the incident contains “Login” as an affected component, your login page can filter on that.