7 results found

1. 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.

   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… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  APIs  ·  Delete…  ·  Admin →
   Released  ·  AdminVadim Solovey (CEO, DoiT) responded

   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!

   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… more

2. Add acknowledgement and alert dates to Cost Anomalies API

   Would it be possible to add new fields to the data returned by Anomalies API? Namely:
   - acknowledgement timestamp
   - first notification sent timestamp (as this is not the same as anomaly start)

   These pieces of data are critical for tracking internal SLAs on cost anomalies but are currently missing and have to be inferred and approximated from other sources.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  APIs  ·  Delete…  ·  Admin →
   Released  ·  AdminNikola (Admin, DoiT) responded

   We've now released the requested attributes as `acknowledgedAt` and `notifications` to both the List and Retrieve Anomaly endpoints. See our developer docs for more information: https://developer.doit.com/reference/listanomalies.

   
   

   Please let us know if this release serves the intended purpose.

3. Service accounts for API use

   Hello,

   It'll be a good feature to be able to create read-only API keys, so the API access can be automated with less risk.

   Thanks

   7 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Released  ·  2 comments  ·  APIs  ·  Delete…  ·  Admin →

4. Swagger/OpenAPI Spec

   Please publish a full Swagger/OpenAPI spec for your API so we can generate type-safe clients in a language of our choice. This makes the time to value much quicker with the API.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  APIs  ·  Delete…  ·  Admin →
   Released  ·  AdminSebastian Caparroz (Admin, DoiT) responded

   The YAML file can now be downloaded by clicking on the "OpenApi" button in our Developer Docs (https://developer.doit.com/reference)

   Direct link: https://developer.doit.com/openapi/doit-api.yaml

5. Sharing support for report API

   When creating a Report, the default visibility is set to "private" in the console. Using the API (and TF provider), it would be nice to be able to set the visibility of the report.

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Released  ·  0 comments  ·  APIs  ·  Delete…  ·  Admin →

6. add more relevant fields to cost anomaly api

   just feedback on the cost anomaly feature on doit console: it is awesome!!
   we are using the API to pull the events and show them internally to the corresponding teams
   feature request: can we get some more critical fields on the api response
   we are missing mainly the status : is the alert still active or not
   idealy the end_date of an alert would be awesome, since you have that information and you show it on the UI

   2 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  APIs  ·  Delete…  ·  Admin →
   Released  ·  AdminFrancisco (Admin, DoiT) responded

   Hello Zakaria,

   Thank you again for your valuable feedback. We're happy to inform you that we've implemented the requested feature. We hope you enjoy it! Your input is essential to us, so please don't hesitate to share any other ideas you may have.

   Best regards,

   Francisco

7. Interact with DoiT Navigator using Terraform
   6 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  APIs  ·  Delete…  ·  Admin →
   Released  ·  AdminSebastian Caparroz (Admin, DoiT) responded

   DoiT Cloud Intelligence™ Terraform Provider is available to be used:

   https://registry.terraform.io/providers/doitintl/doit/latest/docs

   
   

   You can read the documentation on our developer hub:

   https://developer.doit.com/docs/tf-provider