API Upgrades and Enhancements

mjones
mjones Member Posts: 185 ✭✭✭✭
edited December 2023 in Scripts

I will start off saying that I am by no means an API expert.
I come from the MSP space and I am seeing some big limitations that the big player have that Atera does not. That said there is a lot available here that they don't have.

To be honest, I would prefer that some of these limitations be fixed in the GUI, so that we didnt have to use the API.
For Example, being able to create a ticket natively from a script's output should be available. This is a basic requirement that I think should be added ASAP.

I am diving into automation's and I am looking at the API as a work-around for limitations in the system, but I am finding further limitations in the API. I have created a number of enhancement requests but thought I would bring them up here for further visibility and discussion.

API Security:
Having a single API key is a bit scary and short sighted in my opinion. We should be able to have multiple keys for each purpose\integration. This way if we needed to remove an integration, we could just remove that specific key and not break everything else we have it tied to.
https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/45164521-multiple-api-keys-per-account
https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/44971675-have-separate-read-and-read-write-api-keys
https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/46247899-api-security
…

API Limitations:
I am finding that the API has a lot of options, but seems to be lacking a number of obvious features.
https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/47072161-api-create-ticket-from-agentid

First, we should be able to create a ticket tied to an agent instead of a user. This seems like a no brainer in the sense that if we are running a script against a machine and need to create a ticket, we will have the machine info available (ie. Name, Client, Serial Number,…) but not necessarily the user information.
https://atera.uservoice.com/forums/936306-ideas-and-feedback/suggestions/45341659-scripting-tool-to-open-manage-close-ticket

Second, the API documentation is lacking in the sense that there are no examples for using the API in any scripting languages like PowerShell. It would be great to have a couple examples of GETs and PUTs, nothing comprehensive, but something would be nice. There are examples for using the API test page, but nothing in terms of real world usage.
https://support.atera.com/hc/en-us/articles/219083397-APIs

Lastly, being able to manage tickets directly from a script's output is basic functionality that needs to be added. This is a non-started for a lot of MSPs and needs to be added ASAP. The whole point of automation is to be able to automate things. If a script runs and needs intervention, we are supposed to send an email to the ticketing system from PowerShell? This is a huge hole in basic functionality and needs to be added to compete at all with other vendors, and for those of us who use Atera.

Tagging @nina and @Sarah_from_Atera for visibility. I would love to talk to a product manager to give them some pointers and suggestions for frankly some basic features that would make the overall experience MUCH better and enticing for MSPs and IT Departments.

Tagged:

Comments

  • sarah+success
    sarah+success Member Posts: 70 ✭✭

    Hey @mjones , thanks for bringing this to our attention.

    I am reaching out to our Product team, and we will get back to you soon with follow-up, as this is a very detailed post.

    Thanks for your patience, and trying to make Atera better 💪

  • jje
    jje Member Posts: 1 ✭
    edited August 2023

    Hi,

    I'd like to contribute to this, as i've used your API in several occations and it lacks the ability to get invoices/tickets from a specific date period. It's alot to have to pull all invoices/tickets everytime.

    It also puts alot of unnessary work on your servers.

  • Yakov
    Yakov Internal Posts: 17 ✭✭✭

    Hey @mjones,

    First of all, thank you for the feedback and remarks.
    As the product manager in charge of PSA, I'd love to understand and comment on some of these. I'll let my colleagues address remarks regarding the overall infrastructure of the API.

    Regarding the creation of a ticket from a script - May I ask when would this script be fired?
    We've recently introduced Script-based thresholds. With that - you can define that alerts will be created based on script outputs (numbers or text). These alerts can be of course automatically or manually turned into tickets,

    https://support.atera.com/hc/en-us/articles/7305491749276-Script-based-threshold-monitoring

    Regarding the creation of tickets using agentID - I understand the need. We're considering allowing the option to create tickets attached to devices without assigning requestors. If we implement this, we will certainly provide this support within the API down the line.
    That said, today you can create a ticket from the agent page, do you find this option too limiting for when a script ran and you want to open a ticket based on the output (manually)?

    If you don't mind sending me a pm, I'd love to hear of your experience with RMMs that provided this type of automation in the way you're looking for.

    Again, I want to thank you for the detailed explanations and links to the features board. As you might have noticed, we are actively working on enhancing our API. Recent additions include abilities such as getting and posting comments to tickets, and seeing rate amounts and IDs on time entries - both of which came from our community feedback.

    Yakov


  • mjones
    mjones Member Posts: 185 ✭✭✭✭
    https://community.atera.com/discussion/comment/550#Comment_550

    Hey Yakov,

    I would like to start out that I am not dis-satisfied in the product. The value is great and the support has been amazing so far (I am sure they all know me by name already…)

    I appreciate you reaching out and I will DM you so that we can discuss further.

    Regarding the scripts, I might be over or under thinking it, and would appreciate input on adjusting my thought process. I come from a larger MSP who used a lot of automation.

    For example: (May not be the best example, but hopefully will get the point across)
    If we are triggering a script from a threshold for high levels of temp files for example.
    1. Threshold triggered and runs an auto remediation script
    2. The script is able to clean items but not to the level expected
    3. I would be looking for feedback from the script to see where it had an issue, as the original threshold alert doesn't have the latest information, or that anything was successfully done to try to resolve it.
    4. The script should be able to independently create a ticket via the API (based on the agentID) or natively (via the scripting engine looking at exit codes from PowerShell or something), stating that it ran but either failed or was not able to fully remediate.

    I was able to find a sort of work around in creating another alert via the API, which works, but seems like a kludge. (PowerShell snippet attached)

    Sample code.txt

    Additionally, it appears as though the Alert API field "Additional Info" isn't working or I am missing something since it doesn't seem to come through to the alert. Meaning that all I can get across is a "title".

    I don't mind having to use the API, but as I start to use the system more, I am seeing some room for improvement due to lacking GUI features.

  • Yakov
    Yakov Internal Posts: 17 ✭✭✭
    https://community.atera.com/discussion/comment/552#Comment_552

    So if I'm understanding correctly - you'd want a threshold to be met - and based on the remedial action's output to decide upon creating a ticket or not? Would you still document the initial alert that was triggered by the threshold as a ticket?

  • mjones
    mjones Member Posts: 185 ✭✭✭✭
    https://community.atera.com/discussion/comment/595#Comment_595

    That's a fair question.

    So in my example the initial threshold would likely still be unsatisfied. I would personally be looking to do would be to add additional notes to the alert\ticket of what was done already and the the current status of the issue, not just the initially failed threshold.

    I see in the API, that you can get the Ticket ID of a given alert (assuming one was created if the severity was met), but I don't know how you would feed that to a remediation script so that it could add notes to a given ticket. I think that a lot of quirks would be satisfied with being able to feed variables into scripts, and have a set of global variables like an API key for example. But that is a separate suggestions aside from the API comments.


    So an ideal example would be:

    • Threshold fails
    • Alert is generated
    • Auto-healing script is triggered (Atera feeds the script the triggering alertId)
    • Script attempts to fix the issue and fails or completes partially
      • Threshold may or may not be completely satisfied
    • Script adds notes to the ticket
      • Calls "get /api/v3/alerts/{alertId}" to get the TicketID then calls "post /api/v3/tickets/{ticketId}/comments" to add a comment to the ticket.
    • Tech looks at the issue and remediates by hand or another script.

    I also could be overthinking this whole thing, but I think there are some benefits and improvements here.

  • matt.hardwick
    matt.hardwick Member Posts: 2 ✭

    I have been asking for scoped, limited and multiple API keys for like 2 years now… there is also a LOT of data missing from the API - so totally with you! The whole thing needs an update!

  • tanderson
    tanderson Member Posts: 279 ✭✭✭✭

    @MJones Great Post!

Topics