Would it be possible to add support for querying tickets using a from/to datetime range? This functionality would be extremely helpful for automation and reporting purposes, and it would greatly improve our ability to efficiently retrieve relevant ticket data.

Add an API field or endpoint (for example parent_ticket_id on ticket create/update) to manage parent/child relationships

Hi Gil,
any update on that?

I would like to propose another type of variable for scripts that is more secure, for things like API keys.

There could be a secrets manager area with names for each secret, for example, "atera-api-key". Then the script could have something like {[secret=atera-api-key]}.

This would help us automate scripts that have sensitive information and ensure those keys aren't saved in plain text within the script.

This has been open since 2022 with no pickup? That's alarming.

I’m reaching out to highlight a challenge we’re facing with data retrieval in Atera and to request improvements that could streamline our workflows and enhance efficiency.

Currently, we rely on fields such as CustomerName, ScriptName, ScriptCategory, DeviceName, and others for managing processes and creating tickets. While the existing structure and tools are helpful, extracting and utilizing this data in a programmatic and scalable way can be cumbersome.

The Challenge:

The current methods require manual effort or complex workarounds to gather and process information from the above fields.
Automating workflows, such as linking data from scripts or devices directly into ticketing systems, is limited due to a lack of easily accessible API endpoints or consolidated data access methods.
Filtering and processing large datasets, such as script execution results or device statuses, are time-intensive and prone to errors.
Proposed Solution:
I’d like to request enhancements to the Atera platform, specifically:

Expanded API Functionality:

Endpoints that allow direct access to detailed data for fields like CustomerName, ScriptName, and ScriptCategory.
Support for advanced filtering and aggregation.
Unified Data Access:

A single method to retrieve device statuses, script execution details, and customer information in a unified response.
Streamlined Integration:

Easier methods to link retrieved data directly into tickets or other automated workflows.

Folder management :

Get Folders <Customer> doesn't exist
Post ( rename ) <Customer>, <folder> doesn't exist
Create New folder ( doesn't catch duplicate folder names )

It would be great to fetch a lot of tickets for a given date range.
We have tools for analytics and currently have to send a lot of fetch requests to generate statistics for specified month.

Please add a from and to date for the request and increase the returned items per page on the response.

Thank you very much

This idea is posted on behalf of Guillaume Duval:

The script part in Atera needs to evolve with usage of API and variable. First thing is that we need a descent way to get the AssetID on the local machine, in order to call the API with the real agent, as Get-AteraAgent call the API with the Agent's computer's name, which is not unique. On the next step, like SuperOps does, you'll need to embeds the module, with the integrated API key, so we could create script without saving the API key inside script and without the need to download the PSAtera. Would you mind to help me go forward quickly? I can do a call with your team if needed if you need more explaination.

Possibility to restrict API Access from defined IP List in https://app.atera.com/new/admin/security
A simple checkbox can improve security to prevent access from not allowed IPs if api is used for internal purposes only.

The API allows, among other things, to retrieve information from conversations. If confidential data is stored in the conversations, it could be a serious cybersecurity issue (Password). API calls should be authenticated and, in my opinion, API calls should be restricted to only certain public IPs. As with the portal login, which has this option. We could even rely on the same IPs that are allowed to authenticate to the portal. Authentication + IPs = security

Is it possible to allow the current API ton include Serial Number, Device Manufacturer, or Device Model.

Please add the ability to create categories using the knowledge base API. It would be great to also have all knowledge base actions, available in the API.

Currently, we want to use the API to:
* Create new customers
* Create knowledge base that is customer specific

Thanks

Several Customers are accessing Web.API and we need to know if the Web.API is reachable and functional (login)

https://betterstack.com/community/comparisons/api-monitoring-tools/

I would also like to see this.
Seems like a no brainer security feature that all of the other players have.

Duplicate contracts via API

When using the API to modify contacts, the email field is not editable. However, in the web interface, you can edit the field. This implies that it's not a data model restraint, but a restraint in the API.

We currently have customers who move between domains periodically and we have to update their email addresses. We'd like to manage that through an API automation from an external operations system.

API calls to be able to update the update the data of an agent (PUT/PATCH)

API ability for end-customers: option to allow API access of customers. It would be useful for some of our clients.

Configure the IP or FQDN that the API Key can be called from.