canonical: https://jentic.com/apis/atera.com/atera

# Atera API

Atera is an all-in-one remote monitoring and management platform built for managed service providers and internal IT teams, covering agents (endpoints), alerts, customers, contracts, tickets, billing, and patch management. The API exposes the full operational surface - registering and inspecting agents, raising and resolving alerts, managing customers and contracts, billing time entries, and orchestrating patches across managed devices. It is structured around long, paginated list endpoints under `/api/v3` and is well suited to MSPs that need to lift Atera data into reporting, ticketing, or accounting systems.

## For AI agents

Manage Atera agents, alerts, customers, contracts, tickets, and patches programmatically - the building blocks of an MSP back office.

## Scope

Does not handle remote desktop sessions, scripting execution, or billing payment processing - use for Atera agent, alert, customer, and patch management only.

## Capabilities

- List, retrieve, and remove monitored Atera agents (endpoints) across customers via `/api/v3/agents`
- Raise and resolve infrastructure alerts using `/api/v3/alerts` and inspect alert detail by id
- Read installed and available patches per agent through `/api/v3/agents/{deviceGuid}/installed-patches` and /available-patches
- Find agents that belong to a specific machine name or customer for triage workflows
- Pull account-level information for the Atera tenant via `/api/v3/account`
- Drive alert lifecycle automations - open, acknowledge, close - without operator clicks

## Use cases

### MSP Alert Triage Automation

Managed service providers run Atera as the central RMM and want alerts to flow into their ticketing tool with the right customer attribution. The Atera API's `/api/v3/alerts` and `/api/v3/agents` endpoints let a triage agent pull new alerts, resolve the affected agent and customer, and open a ticket in the MSP's helpdesk within seconds. This collapses the alert-to-ticket loop for high-volume MSP environments.

Example prompt: Poll GET `/api/v3/alerts` for new open alerts, fetch the parent agent via `/api/v3/agents/{agentId}`, and open a ticket in the MSP helpdesk

### Patch Compliance Reporting

MSPs need patch compliance reports per customer for monthly client reviews. The `/api/v3/agents/{deviceGuid}/installed-patches` and /available-patches endpoints expose per-device patch state, so a reporting agent can roll up coverage per customer and surface devices missing critical patches. The output drives both client-facing reports and internal remediation backlogs.

Example prompt: For customer 4210, list each agent and call `/api/v3/agents/{deviceGuid}/available-patches`; flag devices with more than 5 outstanding critical patches

### Agent Inventory Sync

Operations teams maintain a master inventory in a CMDB or asset register and need it to reflect Atera reality. The `/api/v3/agents` endpoints, including filters by customer and machine name, let a sync agent reconcile the CMDB with the live Atera agent list, removing decommissioned endpoints and adding new ones. The flow runs on a daily schedule against the Atera tenant.

Example prompt: List all agents for each customer, diff against the CMDB asset register, and create or remove records to match

### Atera Operations via Jentic

Through Jentic, an AI agent fielding 'how many open alerts does customer X have?' searches by intent and Jentic returns the matching Atera operation with its parameters. The Atera api-key credential is held in your Jentic One instance, so the agent never sees the raw key. This makes MSP operational questions answerable inside any LLM chat or runbook.

Example prompt: Use Jentic to search 'list open alerts for customer', load GET `/api/v3/alerts`, filter by customerId, and return the count by severity

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/api/v3/account` | Get tenant account info |
| GET | `/api/v3/agents` | List agents across customers |
| GET | `/api/v3/agents/{agentId}` | Get a specific agent |
| DELETE | `/api/v3/agents/{agentId}` | Delete a decommissioned agent |
| GET | `/api/v3/agents/customer/{customerId}` | List agents for a specific customer |
| GET | `/api/v3/alerts` | List alerts |
| POST | `/api/v3/alerts` | Create an alert |
| GET | `/api/v3/agents/{deviceGuid}/installed-patches` | Get installed patches for an agent |

## Key resources

- **Account** — Read tenant-level account info
- **Agents** — List, retrieve, and remove monitored Atera agents
- **Alerts** — List, retrieve, and create alerts on monitored devices
- **Patches** — Inspect installed and available patches per agent
- **Customers** — Manage customer records linked to agents and tickets
- **Contracts** — Manage MSP contracts and entitlement records
- **Tickets** — Read and update helpdesk tickets attached to customers

## Why Jentic

- **Setup:** Wiring Atera by hand means handling its API-key auth across agent, alert, customer, and patch endpoints and tracking agent and customer ids yourself. Through Jentic you install once, import the Atera API from the API Directory, store the key once, and your agent calls it while Jentic sets the auth header.
- **Permission scoping:** Atera puts the agent and customer id in the URL path (`/api/v3/agents/{agentId}`, `/api/v3/agents/customer/{customerId}`), so a rule can pin your agent to reads for one agent or customer. You choose the operations it may call, so agent deletion is not included unless you add it.
- **Credential handling:** Your Atera API key is stored once, encrypted, by your own Jentic One instance and set as the auth header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list open Atera alerts for a customer', and Jentic returns the matching `/api/v3/alerts` or `/api/v3/agents` operation with its parameters so the agent calls the right endpoint without reading the reference docs.

## Related APIs

- **SyncroMSP** — MSP platform combining RMM, PSA, and ticketing
- **Freshdesk** — Helpdesk platform commonly paired with Atera as the ticketing front end
- **New Relic** — Full-stack observability platform with APM, logs, and infrastructure

## FAQ

### Does Atera publish an official OpenAPI spec for the Atera API?

Atera publishes its own API specification at https://app.atera.com/swagger/docs/v3. It is served from Atera's app domain, and an unauthenticated request returns an empty response, so it is not an anonymous download. The specification here is written and maintained by Jentic so that AI agents and developers can call Atera API through structured tooling without an Atera login. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Atera API use?

The Atera API uses an API key issued from the Atera admin console. Through Jentic, the key is held in the encrypted vault and the auth header is set at call time, so the agent never sees the raw key.

### Can I list all agents for a specific customer?

Yes. GET `/api/v3/agents/customer/{customerId}` returns the agents linked to a single customer, paginated. This is the recommended path when scoping inventory or alert workflows to one tenant within an MSP.

### What are the rate limits for the Atera API?

Atera throttles per API key with a published per-minute quota - back off on HTTP 429 responses and prefer paginated list reads (limit + page) over polling per agent or alert id.

### How do I pull installed patches for a device through Jentic?

Search Jentic for 'get installed patches for an agent', load GET `/api/v3/agents/{deviceGuid}/installed-patches`, and execute with the device guid. Jentic injects the api-key header and validates the path parameter.

### Can I create alerts through the Atera API?

Yes. POST `/api/v3/alerts` creates an alert against an agent. This is useful for piping alerts from a third-party monitor into Atera so the existing helpdesk workflow stays the single source of truth.

### Is the Atera API limited to read operations?

No. Read endpoints dominate, but the API supports creating alerts, deleting agents, and other write operations across customers, contracts, and tickets - enough surface to drive day-to-day MSP automations.

### Can I limit what my agent is allowed to do with the Atera API?

Yes. Because you run Jentic One yourself, your own rules decide which Atera operations and credentials the agent may use. Atera puts the agent and customer id in the URL path, such as `/api/v3/agents/{agentId}` and `/api/v3/agents/customer/{customerId}`, so you can pin the agent to reads for a single agent or customer. You choose the operations it may call, so a destructive call like DELETE `/api/v3/agents/{agentId}` is not available to the agent unless you add it.