Automating Alert Closure via Incident Response Automation & API Access

[robyfr]

Hello UTMStack Community and Developers,

We are currently exploring ways to enhance our incident response workflow with UTMStack. Specifically, we are implementing an automation script that triggers when certain alerts are raised. A key part of this automation would be to automatically close the originating alert within UTMStack once our incident response script has been executed successfully.

We have a few questions regarding this and would greatly appreciate any guidance:

API for Alert Management: Is there an existing API within UTMStack that allows for the programmatic closure (or status update) of alerts? If so, could you please point us to the relevant documentation or provide some information on how to interact with it for this purpose?

API Key Creation: To utilize the API (if available), we would need to authenticate our automation script. We haven't been able to locate documentation on how to create or obtain API keys for UTMStack. Could you please provide instructions on how to generate API keys within the UTMStack interface or via any other method?

Passing Alert Context to Automation: When an incident response automation is triggered by an alert, is it possible to pass contextual information about that specific alert to the automation script as a variable? Ideally, we would like to receive a unique identifier (like an alert ID or number) that our script can then use to reference and potentially close the alert via the API. If this is not currently supported, would it be a feasible feature request?

Our goal is to create a more streamlined and efficient incident response process where the system can automatically acknowledge and close resolved alerts, reducing manual intervention and ensuring a cleaner alert overview.

Thank you for your time and assistance with these questions. We are eager to learn more about UTMStack's capabilities in this area.

Sincerely,

[rvald26]

Hi!,

Yes, you can find our API documentation here. All UTMStack alert management functionalities are available through the API.
https://documentation.utmstack.com/v10/api-reference/logs-resource/get-managementlogs

Regarding automated closure of alerts, this is a great idea. I added it to our internal backlog so its an option in the SOAR workflow.

Regarding alert contextual information, yes, just press tab in the command input window (last step in wizard) and you will get many variable options to obtain from the alert. you could potentially include these context info in a curl to your automations script.

[robyfr]

Hi rvald26,

thank you very much for your prompt response and for adding the automated alert closure to your backlog – that's great news!

Regarding the API documentation link you provided for /management/logs, I had actually found that page previously. However, I'm still unclear on how to obtain the authentication token required in the Authorization header. The documentation mentions "Bearer " but doesn't specify the process for generating or retrieving this token. Could you please provide more information or point me to the relevant documentation on how to get the API token?

Regarding the alert contextual information and the TAB suggestion in the command input window, I appreciate the clarification. I've explored the available variables, but it seems there isn't a specific variable that directly contains a reference or ID of the alert that triggered the incident response automation.

This would be very useful for passing context to external automation scripts. Could you please advise if such a variable exists or if there's another way to reliably identify the triggering alert within the automation workflow?

Thank you again for your assistance.
Best regards,

Roberto

[rvald26]

Custom alert variables will be available in our next major update v11. This will be live in 2 weeks :)

Regarding bearer token you can get it like this:

Obtain bearer token:
curl -X POST "http://your-utmstack-server/api/login"
-H "Content-Type: application/json"
-d '{"username":"utmstack","password":"utmstack"}'

Use it:
curl -X GET "http://your-utmstack-server/api/secure-endpoint"
-H "Authorization: Bearer YOUR_BEARER_TOKEN"

[robyfr]

Thank you so much for your continued patience and help with this. I'm still encountering an issue when trying to obtain the bearer token. Despite using the curl command you provided:

curl -X POST "https://my-utmstack-server-fqdn/api/login" \
-H "Content-Type: application/json" \
-d '{"username":"utmstack","password":"utmstack"}'

I consistently receive the following response:

{"status":401,"error":"Unauthorized","path":"/api/login"}
I've also tried various username/password combinations that I've found or configured, including:

1. "utmstack" / "password found in utmstack.yml"
2. "admin" / "password found in utmstack.yml"
3. "admin" / "my modified admin password"
4. "email address associated with admin" / "my modified admin password"

None of these attempts have been successful.

Interestingly, I did a test using Chrome's developer tools (F12, Network tab). I searched for "Bearer" in the requests and found a token. I then used this token in a subsequent curl call to /api/utm-alert-logs (as an example), and that call was successful.

This makes me even more uncertain about how to programmatically obtain a valid bearer token using the /api/login endpoint. I'm wondering if a specific API user needs to be created separately (and if so, where this creation process takes place), or if there are other default credentials I should be using for the /api/login endpoint. Any further guidance on this would be greatly appreciated.

Best regards,

Roberto

[alaynsn]

Hi Roberto,

Thank you once again for your detailed feedback, your patience, and for the troubleshooting you’ve already carried out.

You’re absolutely right to be confused — and we sincerely apologize for the inconvenience. It appears there was a miscommunication regarding the correct authentication endpoint and process.

To clarify: the /api/login endpoint previously referenced is not valid for bearer token generation in the current version of UTMStack. The correct authentication method involves a different endpoint and payload structure.

To address this properly, we’ve published an updated and detailed guide in our official documentation that walks you step-by-step through the correct process for authenticating and obtaining a bearer token to interact with the UTMStack API:

🔗 UTMStack API Authentication Guide

Please follow this guide carefully to:
• Authenticate successfully
• Retrieve a valid bearer token
• Begin interacting with secured API endpoints using that token

Thanks again for your collaboration, and we look forward to helping you get up and running smoothly.

Best regards

[robyfr]

Hi alaynsn,

thank you all again for your detailed response and for clarifying the situation regarding the authentication endpoint. I really appreciate your patience and the publication of the updated guide.

I carefully followed the instructions in the document and I'm pleased to confirm that I was able to authenticate and successfully make several API calls using the obtained bearer token.

During these tests, I noticed a couple of aspects that might be helpful to other users or could benefit from clarification in the documentation:

API User Creation: To use the APIs with a dedicated user (other than admin), it's necessary to create one specifically within UTMStack. However, this user is required to have a unique email address, even if it's solely for API usage.
Two Factor Authentication: I found that with Two Factor Authentication enabled at the system level, API user authentication to obtain the bearer token fails. The curl call responds with "authenticated":false". This indicates that, currently, API authentication for a bearer token is incompatible with system-wide 2FA being active.

Finally, I have a question regarding the APIs for threat management. I was looking for a way to consult via API the information I normally view in the "Threat Management / Alert" menu. I tried the /api/utm-alert-logs endpoint, but the data returned seems to refer to closed alerts or, in any case, I don't fully understand their nature and whether they represent the real-time view of active alerts. Could you please provide more guidance on which APIs to use to access this information?

Thanks again for your support and your availability. I'm excited to integrate UTMStack with my systems, and any further clarification will be valuable.

Best regards,

Roberto

[rvald26]

Please open a support ticket for extended support related to API utilization. Marking this discussion as answered since the original question has been cleared.