# Modify REST API for get alerts

**URL:** <https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441>\
**Category:** Alerting\
**Created:** [October 26, 2021, 12:47pm UTC](https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441 "2021-10-26T12:47:20Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![poojamehta\_ids](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@poojamehta\_ids](https://forum.opensearch.org/u/poojamehta_ids)\
**Post date:** [October 26, 2021, 12:47pm UTC](https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441/1 "2021-10-26T12:47:21Z")

</div>

Hi, I want to update the REST API used for fetching alerts so that it includes other fields related to that alert in the API response. Can anybody let me know whether it is possible or not? If yes, how can this be done?

---

<div class="post-metadata">

**Author:** ![qreshi](https://avatars.discourse-cdn.com/v4/letter/q/aca169/32.png) [@qreshi](https://forum.opensearch.org/u/qreshi)\
**Post date:** [October 26, 2021, 8:59pm UTC](https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441/2 "2021-10-26T20:59:39Z")

</div>

Hi @poojamehta_ids,

If you mean that you’d like modify the Alerts themselves so they contain additional information and then have that reflected in the Get Alerts REST API response then you can add the additional information/fields you want stored to the [Alert data class](https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/kotlin/org/opensearch/alerting/model/Alert.kt#L46-L66) and then update the [toXContent](https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/kotlin/org/opensearch/alerting/model/Alert.kt#L306) and [parse](https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/kotlin/org/opensearch/alerting/model/Alert.kt#L216) so that data can be indexed and subsequently read back.

You might also want to update the [alert mapping](https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/resources/org/opensearch/alerting/alerts/alert_mapping.json) so it recognizes the field the way you want it to.

The [Get Alerts API](https://opensearch.org/docs/latest/monitoring-plugins/alerting/api/#get-alerts) is essentially returning a search response format of the fetched Alerts so these changes should be sufficient to have those additions reflected in there.

If you have a specific example, I might be able to provide further assistance if the approach above isn’t what you’re looking for.

---

<div class="post-metadata">

**Author:** ![poojamehta\_ids](https://avatars.discourse-cdn.com/v4/letter/p/f17d59/32.png) [@poojamehta\_ids](https://forum.opensearch.org/u/poojamehta_ids)\
**Post date:** [October 27, 2021, 5:39am UTC](https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441/3 "2021-10-27T05:39:59Z")

</div>

@qreshi Thanks, this helps. Can you please let me know any specific index from which they are fetching Alerts related data, so I can add fields to the Alert data class accordingly.

---

<div class="post-metadata">

**Author:** ![qreshi](https://avatars.discourse-cdn.com/v4/letter/q/aca169/32.png) [@qreshi](https://forum.opensearch.org/u/qreshi)\
**Post date:** [October 27, 2021, 6:27pm UTC](https://forum.opensearch.org/t/modify-rest-api-for-get-alerts/7441/4 "2021-10-27T18:27:59Z")

</div>

@poojamehta_ids,

Active Alerts are stored in `.opendistro-alerting-alerts` and if the alert history option is enabled, `COMPLETED/DELETED` Alerts will be moved to history indices of the pattern`.opendistro-alerting-alert-history*`.

All of those indices use the `alert_mapping.json` mapping I linked above. If you do update this mapping, I suggest also incrementing the [schema version](https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/resources/org/opensearch/alerting/alerts/alert_mapping.json#L7) so if you upgrade to a version of Alerting with your changes while already having Alerting and its indices present on a cluster, it will recognize the update.
