Allow an anomaly's status to be updated programmatically via the API.
The Anomalies API is currently read-only (GET /analytics/v1/anomalies and GET .../anomalies/{id}). There is no way to change the state of an anomaly through the API.
Please add a write path - for example PATCH /analytics/v1/anomalies/{id} -supporting an acknowledge / dismiss / resolve state transition, ideally with an optional note or external-reference field so an anomaly can be linked to a record in an external system. This would mirror the status-update capability the Insights API already provides via PATCH /insights/v1/sources/{sourceID}/insights/{insightKey}.
This may also merit adding another endpoint to the API for listing ackowledement reasons.
Use case:
Teams that automate FinOps workflows need to reflect an anomaly's resolution back in DoiT once it has been handled elsewhere. Without a write path, anomaly state can only be tracked outside DoiT, so the two views drift apart and the same anomaly gets reviewed repeatedly. A simple status write-back keeps DoiT aligned with downstream automation and avoids duplicate triage.
Dawid Piotrowski
shared this idea
We've added a write path to the Anomalies API that mirrors the console's review workflow:
```
PATCH /anomalies/v1/{id}
```
You can now set an anomaly's `reviewStatus` (`NEEDS_REVIEW`, `UNDER_REVIEW`, or `RESOLVED`), qualify a resolution with `ANOMALY_CONFIRMED` or `NOT_ANOMALY`, and optionally attach a `resolutionNote` with a feedback reason and comment.
Feedback reasons cover both directions — e.g. `MISCONFIGURATION`, `UNINTENTIONAL_PROVISIONING`, and `EXPECTED_COST_SPIKE` for confirmed anomalies; `FAULTY_ANOMALY_DETECTION_MODEL`, `LOW_IMPACT`, and `INCORRECT_DATA` for non-anomalies — so your automation can close the loop on triage done in external systems.
A few notes based on your suggestions:
- **Acknowledgment reasons** are documented directly in the OpenAPI spec as self-describing enums (no extra endpoint needed), including which reasons are valid for each resolution — validation is enforced server-side.
- The change is recorded in the anomaly's review history and feed exactly like a console update, so DoiT and your downstream tools stay in sync without duplicate triage.
- It requires the Anomalies Manager permission and DoiT API access, and the actor on the change is derived from your API credentials.
See the [API documentation](https://docs.doit.com) for the full request/response details. If you build something with it, we'd love to hear how it fits your FinOps workflow!
