Connecting Atera to third-party services and Atera ticketing actions lets you automate more of your workflows and reduce manual work for your team. You can trigger different actions in external platforms — or activate Atera ticketing APIs like escalating, resolving, listing, and retrieving tickets — all from Atera, using dynamic, parameter-based calls to each service’s API. This keeps your systems in sync, lets you pass context (like device, site, user, or ticket details) into those actions, and helps you build richer, end-to-end processes around your monitoring, automation, Robin, and ticketing workflows.

Overview

Cloud actions define how Atera talks to external services and ticketing APIs — which API endpoint to call, which parameters and headers to send, and what data to include in the request body. You can combine static values (like authentication and fixed settings) with dynamic values pulled from tickets, devices, users, or user input, and even let AI Copilot generate the initial action for you. This gives you a flexible way to build and reuse integrations as part of your monitoring, automation, Robin, and ticketing workflows.

Cloud actions can also activate Atera ticketing actions, including escalating tickets, resolving tickets, listing tickets, and retrieving ticket details. This lets AI Copilot and Robin help move ticket workflows forward using the right ticket context at the right time.

Parameters

Parameters let you pass additional data to the API endpoint, such as filters, locations, or resource identifiers. They can be added as query parameters or path parameters, depending on the API specification.

• Static parameters: Use static parameters for values that stay the same every time the action runs (e.g., a fixed country code, a default status, or a specific API version). These are entered once and reused in every request.
• Dynamic parameters: Use dynamic parameters for values that can change at runtime and should come from the user or from context (e.g., device ID, customer ID, city name, or ticket ID). You define the parameter name and a description, and AI Copilot and Robin will prompt for these values or pull them from the relevant context when running the action.

This allows you to combine static defaults with dynamic, per-request values so the same action can be reused across different customers, tenants, locations, resources, or tickets.

Headers

Headers let you pass additional metadata to the API endpoint, such as authentication, content type, or client information. Each header has a type (Default or Secret), a key, and a value. When you select 'Secret', the value is hidden and can only be revealed by clicking the eye icon.

• Default headers: Use for non-sensitive values that can be safely viewed, or other fixed configuration values.
• Secret headers: Use for sensitive values like API keys, tokens, or credentials. These values are masked to help protect confidential information while still being available to the API call at runtime.

Headers can also be defined as static or dynamic, depending on whether their values stay the same every time the action runs or change at runtime based on user input or context.

• Static headers: Use static headers for values that remain the same in every request, such as authentication and fixed configuration. (e.g., Authorization: ApiKey {{api_key}}). Once you set these up, AI Copilot automatically includes them in each request so it knows how to authenticate and call the correct API without asking the user.
• Dynamic headers: Use dynamic headers for values that can change at runtime and should come from the user or from context (e.g., city, country, tenant ID, or ticket ID). You define the header key and a description, and AI Copilot will prompt for these values or derive them from the current ticket, device, or customer when running the action.

By combining Default or Secret headers with static and dynamic behavior, you can securely reuse the same API action across different customers, locations, resources, and ticket workflows while keeping the workflow flexible and secure.

Request body

Add a request body (in valid JSON format) if your action needs to send data to the target service or Atera ticketing API (for example, creating or updating a resource or modifying a ticket). For dynamic values, wrap the placeholders in curly braces (e.g., {customer_id} or {ticket_id}).

Create a cloud action

When you create a cloud action, you define exactly what should happen in the external service or within Atera (for example, ticketing actions) — which endpoint to call, what data to send, and when it should run. This gives you precise control over integrations, so you can tailor each action to your specific tools, use cases, ticket workflows, and security requirements.

To create a cloud action:

1. Go to AI Center > Cloud actions.

2. Click New cloud action.

The Create cloud action page appears.

3. Enter the name and description.

4. Toggle Robin on or off to let it evaluate user-reported issues and run this cloud action when needed. 

5. Select the HTTP request method (GET, POST, PUT, PATCH, or DELETE). Then enter the full URL of the API endpoint you want this cloud action to call.

6. Fill out the parameters, headers, and body as required by the target service or Atera ticketing action:

• Parameters: Add any query or path parameters the endpoint expects. You can also use dynamic values here by wrapping them in double curly braces (e.g.,  {{ticket_id}}).
• Headers: Add any HTTP headers required by the API (follow the format defined in the respective API documentation).
• Body: Add a request body (in valid JSON format) if your action needs to send data to the target service or Atera ticketing API. To insert dynamic values, wrap them in double curly braces (e.g., {{ticket_id}}).

Best practices for third-party APIs

A cloud action calling an external service sends your data outside Atera and can change state in another system. These are the decisions worth making before you set one to Active.

Check whether you need raw REST at all

A cloud action is the right tool for a product that has an API but no other route into Atera. Where a native integration or an MCP entry exists, use it instead: both are maintained for you, and MCP respects the connected system's own permission model per user.

Reach for a cloud action when the product has neither. See AI Center: Model Context Protocol (MCP) integrations.

Use a least-privilege credential

Important: Create a dedicated credential for the action with only the permissions that action needs, and put it in a Secret header so the value is masked. Do not reuse an administrator key that happens to be available.

Two reasons this matters more than usual. The credential is stored in Atera rather than in the target system, so its scope is the only thing limiting what the action can do there. And Robin chooses when to run the action, so a broadly scoped credential is a broadly scoped capability.

Tip: Give each credential an owner and a rotation schedule at the same time as you create the action. A masked value is easy to forget about.

Decide what data leaves Atera

Dynamic parameters and body placeholders can pull ticket, device, user, and site context into the request. Send only the fields the endpoint needs.

It is easy to pass a whole ticket when the API only requires an identifier, and the difference is invisible once the action is working.

Be deliberate about the HTTP method

Warning: Cloud actions support GET, POST, PUT, PATCH, and DELETE. A DELETE or PUT action changes or removes data in the target system, and Robin decides when to run it.

Start with GET actions, which only read. Add anything that writes or deletes once you have seen how Robin uses the read action, and consider putting a destructive action behind a Playbook with an approval step rather than exposing it directly.

Decide whether Robin should use it

The Robin toggle on each action is the exposure decision. Leaving it off means the action is available to you and to AI Copilot but Robin will not invoke it on its own from a user's request. For anything that writes to a system of record, that is a reasonable default until the action is proven.

Test the failure path, not just the success path

An action that works on a good day is only half tested. Before setting it Active:

1. Run it with valid input and confirm the target system changed as expected.
2. Run it with input the API will reject, and see what Robin does with the error.
3. Confirm the result is visible in the ticket, so a technician picking it up can tell whether the action ran.

Review anything AI Copilot generated

A generated action is a draft. Before activating it, check:

• The URL and method are the ones you intended, particularly that a read operation has not been generated as a write.
• The credential sits in a Secret header rather than a Default one.
• No more context is being passed than the endpoint needs.
• The description is accurate, since Robin uses it to decide when the action is relevant.

Note: The last one is easy to skip and causes the most trouble. A vague description means the action is either never chosen or chosen for the wrong request.

Give every action an owner

Record who owns each third-party action, so that when the target API changes, the credential expires, or the endpoint is deprecated, there is somebody to notice. An action that has silently stopped working looks the same as one that never fires.

Generate actions with AI Copilot

Describe your goal in plain language and let AI Copilot draft the request for you — URL, method, headers, and body, whether it’s for an external service or an Atera ticketing action. We recommend reviewing and fine-tuning the generated action before enabling it, so it aligns with your exact intent and internal policies.

To generate a cloud action with AI Copilot:

1. Click Generate with AI Copilot.

The Generate cloud actions with AI Copilot window appears.

2. Describe the use case.

3. Enter the value that the target system expects in the Authorization header for its API calls. This is usually something like an API key or token. 

Note: If the API doesn’t require authorization, you can leave this field empty.

4. Enter the API documentation URL.

5. Click Generate action.

The action will appear on the Cloud actions page. 

6. Open it, review the details AI Copilot created, and make any needed edits. Then click Save. 

7. Set the status to Active.