Skip to main content
You connect AutoElevate once at the MSP level, then turn it on per agent.
AutoElevate uses a single API key per MSP. Save it once and every agent that has AutoElevate permissions can use it.

​
1. Create an API key in AutoElevate

1

Open a service user

In the AutoElevate admin portal, open a service user and add an API Key.
2

Pick the API Token (AE-BEARER) scheme

AutoElevate offers two schemes at creation. Pick API Token (AE-BEARER) — the value starts with aeb_.
Do not pick HMAC (AE-HMAC-SHA256). That scheme signs every request with a separate key held on your side, and Neo cannot use it. Its values start with aeh_.
3

Give the key its scopes

An AutoElevate key carries an explicit scope list.Grant companyView. Neo reads the company list on every PSA sync to keep the client mapping current, so this one is needed whatever your agents do.Then grant the view scopes for each area your agents read, and requestEdit as well if any agent will approve or deny.
Copy the key somewhere safe once it is generated — AutoElevate shows it only once.

​
2. Add the key in Neo

1

Open Integrations

In the Neo Dashboard, open Integrations and find the AutoElevate card, under Security.
2

Save the API Key

Paste the key and click Save. Neo checks it against AutoElevate before saving, so a wrong or mistyped key is rejected straight away.

​
3. Turn AutoElevate on per agent

Each agent decides whether it uses AutoElevate and which areas it can touch. Open the agent, go to the Integrations section, and configure the AutoElevate block.

​
Pick an access profile

Read Only

Every area set to read only. The agent can find elevation requests, read the evidence behind them, and report — but never decides one.

Helpdesk

Elevation Requests set to read and write — still requires technician approval on every decision. Everything else read only. Fits a helpdesk agent working the “I need admin rights to install this” ticket.
There is no Full Automation profile for AutoElevate. The only write this API has is the one that can never go through unattended.

​
Or set each area by hand

Every area except Elevation Requests is read only, because AutoElevate’s Partner API has no write endpoint for it.

​
Safety controls

  • Approving and denying always wait on a technician. This holds regardless of the agent’s automation level or the access profile you picked. It is not a setting you can turn off. A decision is final: once a request leaves PENDING AutoElevate refuses any further decision on it, and there is no un-approve.
  • Neo does not create rules on its own. Both approve and deny can also create an auto-approval or auto-denial rule, and at account scope that rule decides every future matching elevation across every client you manage. Neo’s agents are told to leave that off unless a technician asked for it in so many words, and the technician sees it in the approval either way.
  • Every other area is read only. Neo cannot change a rule, a computer, a company or a location through this integration, whatever the agent is set to.
  • Path safety. Suspicious URL paths (anything containing .., for example) are rejected before they reach AutoElevate.
  • Neo sets the authentication itself. The API key and AutoElevate’s required beta header are added by Neo on every call. An agent cannot set, replace or read either one.

​
If AutoElevate refuses Neo’s requests

Until a 401 or 403 is fixed, agents that use AutoElevate report the failure on the ticket they were working. The rest of Neo keeps running.

​
Security

  • The API key lives in Azure Key Vault. It is never stored in plaintext.
  • All traffic to AutoElevate goes over HTTPS, to partner-api.autoelevate.com.
  • Write access is opt in per agent, and it is only ever available on Elevation Requests.
Once your key is saved and an agent has permissions, the AutoElevate tool is added to that agent automatically.