# API Version History ## In general We treat the API as first class part of our product and are looking forward to any customer or partner that decides to integrate with us, which is why we are taking API versioning and preventing breaks or interruptions very seriously. We try to prevent breaking changes for our API, however sometimes these are necessary in an evolving world and product space. We consider the following changes to be backwards-compatible: * Adding new API resources * Adding new optional request parameters to existing API methods * Adding new properties to existing API responses * Changing the order of properties in existing API responses ## Notable changes ### Support hours becoming a real resource In November 2023 we changed the inline support hours object of alert sources to a referenced sub resource. This introduces the new `/api/support-hours` CRUD resource, as well as a new field in `alertSource.supportHours.id`. If the ID field is present, the API will treat it as a reference, if it is not, the API will fallback to the legacy behaviour and allow nesting the fields into the alert source. ### Moving user's notification preferences into stand-alone resources In February 2023 we introduced a new management for user contacts and notification preferences. A specific explanation of this change as well as [migration information can be found here.](/developer-docs/api-version-history/api-user-preference-migration-2023.md) ### Dropping URL versions globally While renaming incidents to alerts in October 2021 we dediced that the best way to migrate the API to the new resources and fields was to introduce a new API version, however continuing further we did not want to stick to versioning through url paths in favor of developer experience. Which is why we decided to migrate the new resources away from the version path. #### What did we do to keep backwards compatibility? All old resources running on `/v1/...` are still available. Meaning the new resource and fields that are now available under e.g. `/api/alert-sources` are still available in their old format under `/api/v1/alert-sources`. #### Which migration strategy do we suggest? Integrations that have been developed using the old API version do not have to be migrated, the v1 resources are still available. When developing new integrations however, make sure to use the new resources - which is also why we have removed any old endpoint from our API documentation. ### Renaming incidents to alerts In September 2021 we announced that we would [rename incidents to alerts](https://github.com/iLert/docs/blob/master/developer-docs/getting-started/faq/renaming-of-incidents-to-alerts.md). Explaining that incidents would be reborn as new entity for the next big product extension incident communication v2 and status pages. Of course this also required us to change the API resources. `/api/1/incidents` became `/api/alerts` and `/api/incidents` will hold the new entity. #### What did we do to keep backwards compatibility? The old incident endpoints `/api/v1/incidents` is still available and delivers the old/new incident/alert objects. #### Which migration strategy do we suggest? Integrations that have been developed using the old API version to not have to be migrated, the v1 resources are still available. When developing new integrations however, make sure to use the new resources. **Please also note**: that for the new API (all resources without url versioning) the entities might contain changed field names e.g. `AlertSource.incidentCreation` => `AlertSource.alertCreation` a few fields were subject to this change our API docs are already reflecting this change, you can find them below. | Entity | Old key / value | New key / value | | ------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------- | | User | subscribedIncidentUpdateStates | subscribedAlertUpdateStates | | User | subscribedIncidentUpdateNotificationTypes | subscribedAlertUpdateNotificationTypes | | Connection | triggerTypes | All values e.g. incident-created have been renamed accordingly e.g. alert-created | | UptimeMonitor | createIncidentAfterFailedChecks | createAlertAfterFailedChecks | | AlertSource | incidentCreation | alertCreation | | AlertSource | incidentPriorityRule | alertPriorityRule | | AlertSource.supportHours | autoRaiseIncidents | autoRaiseAlerts | | Incident -> Alert | incidentKey | alertKey | | Notification | incidentId | alertId | | LogEntry | incidentId | alertId | | LogEntry | logEntryType | All values e.g. IncidentLogEntry have been renamed accordingly e.g. AlertLogEntry | | Event | incidentKey | alertKey | ### Renaming connections to alert-actions In favor of developer experience we decided to migrate `/api/v1/connections` to `/api/alert-actions` alongside our [general version dropping migration](#dropping-url-versions-globally). The old endpoint is still available. ### Removing XML support In June 2020 we decided to deprecate XML support for request and response schemas, as JSON was widely preferered by our customers. We began removing support from older `/v1/...` endpoints in August 2020. XML is **not** supported in new url version-less resources as of 2021. #### What did we do to keep backwards compatibility? Resources containing v1 in their url that were receiving XML traffic were kept available. #### Which migration strategy do we suggest? We suggest to send the `accept: application/json` header and providing `content-type: application/json` while switching your clients to JSON processing. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ilert.com/developer-docs/api-version-history.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.