Partner API (BETA)
Create an AutoElevate Partner API key, choose its permissions, and see what the API can read and manage, what is audited, and how to fix common errors.
Written by Daniel Rivera
Updated at October 27th, 2026
Table of Contents
Overview
The AutoElevate Partner API (BETA) allows partners to build custom integrations, reporting solutions, automation workflows, and internal tools using data from the AutoElevate platform.
Unlike the built-in PSA integrations for products such as Halo PSA, ConnectWise Manage, and Zendesk, the Partner API is intended for organizations developing their own integrations and business processes.
Beta Notice
The Partner API is currently in Beta. Functionality, available endpoints, and authentication requirements may change as the platform evolves. Always refer to the official Partner API documentation for the latest implementation details
This article covers one thing: how to create an API key in the Web Admin Portal. For everything else — authentication, endpoints, versioning, rate limits, and the OpenAPI document — see the Partner API reference. The reference is generated directly from the API itself and is always up to date, so those details are documented there and only there.
What Is the Partner API?
The Partner API provides programmatic access to supported AutoElevate resources, allowing partners to retrieve data, manage selected resources, and integrate AutoElevate with third-party systems.
Common use cases include:
- Building custom dashboards and reporting tools
- Creating automation workflows
- Integrating with internal business systems
- Synchronizing data with external platforms
- Developing custom operational and compliance reporting
Available API Capabilities
The Partner API can read and manage supported AutoElevate resources. Each action needs the matching permission on the API key (see Creating an API Key below).
Read: companies, locations, computers, elevation requests, elevation events, elevation rules, elevated sessions, audit logs, and users and roles.
Manage:
- Approve or deny elevation requests
- Edit or delete an elevation rule. A rule's scope (the level it applies at) cannot be changed.
- Add, edit, and delete users
- Turn technician mode on or off for a Windows computer
- Set a computer's elevation mode to Audit, Live, or Policy, or clear the computer's own setting so it inherits the setting from above
- Uninstall the agent and delete a computer, the same as Uninstall Agent & Delete Computer in the portal
Technician mode, elevation mode, and agent uninstall changes are sent to the agent and take effect at its next configuration check-in, usually within a few minutes while the computer is online. Creating an elevation rule from scratch is not available through the API.
Because new endpoints are periodically added during the Beta program, consult the official API documentation for the current endpoint catalog, schemas, and supported operations.
User Types: Human and Service
The portal has two user types, chosen on the first step when creating a user:
- Human — a person who logs in and works in the portal
- Service — a non-person account that represents an integration or automation
You can add API keys to any user of either type, including Human users already in your system. You do not need a Service user to create an API key.
That said, for long-lived integrations we recommend a dedicated Service user rather than attaching the key to a person's account. All API activity is attributed to the user the key belongs to, so a Service user keeps your audit trail clean and means the integration isn't affected when an employee's account changes.
Changes to elevation rules and users made through the API are recorded in the audit log under the key's user. These actions aren't in the audit log, whether you use the API or the portal:
- Approving or denying an elevation request. The request shows the key's user under Responded By. A rule created from the request is in the audit log.
- Turning technician mode on or off, changing a computer's elevation mode, and deleting a computer.
A technician mode session started through the API shows the key's user as the Technician Mode User. If you need to know which technician started each session, give each technician a key on their own user.
Creating a Service User (Recommended for Integrations)
- Navigate to the Users screen and click Add User
- On the first step, select Service as the user type
- Give the user a name that identifies the integration and complete the remaining steps
Creating an API Key
- Log in to the Web Admin Portal at msp.autoelevate.com
- Navigate to the Users screen
- Select the user the key should belong to — the Service user you created above, or any existing user
- In the user's details, open the API Keys section and click Add New (+)
- Configure the key:
- Name — a label that identifies the integration using the key
- Scheme — Bearer (most tooling) or HMAC-SHA256 (signed) (see the Partner API reference for how each scheme is used)
- Scope — Full access, or Limited to specific permissions to grant only what the integration needs. A key can never grant more than the user's own role allows; if the user's role changes later, key permissions no longer covered by the role are flagged in the UI
- Expires — prefer the shortest expiration that works for your use case
- Click Add and copy the key secret(s) immediately — they are shown once and cannot be retrieved again
A key's permissions cannot be changed after it is created. To change what a key can do, create a new key with the permissions you need, update the integration to use it, and then revoke the old key.
Write and delete permissions make real changes. Delete computers uninstalls the agent and removes the computer from the portal. Create users sends the new user an invitation email unless the integration turns it off. A key cannot give a user a role or company access beyond what the key itself has.
Authentication and Request Signing
All Partner API requests must be authenticated with a valid AutoElevate API key, using the key's scheme: Bearer or HMAC-SHA256 (signed). Keys that use the HMAC-SHA256 scheme sign each request with the AE-HMAC-SHA256 method described below.
Request signing validates both the authenticity and integrity of requests sent to the AutoElevate API.
Important: Body Hash Requirement
Partner API request signatures include a body hash as part of signature validation.
Partners maintaining existing integrations should review their implementation to ensure they include body hashing when generating signatures.
Requests that do not include the required body hash, or include an invalid body hash, will fail signature validation and may be rejected by the API.
This requirement helps protect against request tampering and ensures request contents have not been modified during transmission.
How Request Signing Works
Request signing validates:
- The API key associated with the request
- The request contents
- The request timestamp
- The request body hash
- The generated AE-HMAC-SHA256 signature
The API compares the submitted signature against a server-generated signature. If validation fails, the request is rejected.
Authentication Documentation
For complete signing instructions, required headers, signature generation examples, and implementation details, refer to the official Partner API authentication documentation:
Partner API Authentication Guide
API Key Security Best Practices
Use Short Expiration Periods
When possible, use the shortest practical API key expiration period that meets your operational requirements.
Separate Production and Test Environments
Generate different credentials for testing and production workloads.
This reduces risk and prevents test activity from impacting production integrations.
Store Credentials Securely
Store API keys and secrets in:
- Password managers
- Secrets-management platforms
- Secure credential vaults
Never store API credentials in source code repositories or publicly accessible locations.
Rotate Keys Regularly
Establish a process for periodic API key rotation and promptly revoke credentials that are no longer required.
Managing Existing Keys
- Each key shows when it was last used, so unused keys are easy to spot and remove
- Store key secrets in a secrets manager — never in source control, tickets, chat, or shared documents
- If a key is ever exposed, revoke it in the portal immediately and create a new one
- Review keys when personnel or roles change, and revoke keys that are no longer needed
Next Steps
With your key created, everything else lives in the Partner API reference: how to authenticate with your key type, available endpoints, versioning, rate limits, and a downloadable OpenAPI document for generating client libraries.
Troubleshooting: 403 Forbidden
Issue
A Partner API request returns:
403 ForbiddenEven though authentication credentials appear valid and request signing succeeds.
Cause
A 403 Forbidden response typically indicates that authentication succeeded, but the requesting account does not have permission to access the requested resource.
Known causes include:
- Accessing endpoints that require Early Access enrollment
- Missing permissions associated with the API account
- Endpoint-specific access restrictions
- API credentials associated with an account that lacks access to the requested functionality
A common example is a key created with Limited to specific permissions that does not include the permission the endpoint needs, such as Read elevated sessions or Read elevation rules. For audit logs, the key needs Read audit logs plus the read permission for each kind of entry: Read elevation rules for rule changes, Read users and roles for user changes, and both Read settings and Read MSP-level settings for setting changes. Entries the key can't read are left out, and if it can't read any of the entries requested, the API returns 403. A 403 is also returned when the item is in a company the key cannot access.
Resolution
Step 1: Verify Early Access Enrollment
Confirm that your organization has access to any Early Access functionality associated with the endpoint being used.
Some endpoints may require enrollment before access is granted.
Step 2: Verify Permissions
Review the permissions associated with the account that generated the API credentials.
Ensure the account has sufficient access to the requested resources.
Permissions on an existing key cannot be changed. If the key is missing a permission, create a new key that includes it, update the integration, and revoke the old key.
Step 3: Validate Authentication Configuration
Confirm the following:
- API key is active
- API key has not expired
- Request signing is configured correctly
- Body hash requirements are being met
- System clocks are synchronized if timestamps are used
Step 4: Generate New Credentials
If authentication-related issues are suspected:
- Generate a new API key.
- Update the integration configuration.
- Retry the request.
Step 5: Contact CyberFOX Support
If the issue persists after validating enrollment, permissions, and authentication settings, contact CyberFOX Support.
Include:
- Endpoint being accessed
- Approximate request timestamp
- Account information
- Relevant error responses
- Steps already taken
Troubleshooting: Other Responses
404 Not Found
The item does not exist, has been deleted, or is not visible to the key. The API does not confirm whether an ID exists. Check the ID, and check that the key's user can see the item in the portal.
409 Conflict
The item's state does not allow the change. For example, the elevation request is no longer pending, the email address is already in use, or more than one user is active on the computer when turning on technician mode.
422 Unprocessable Entity
The request is valid, but the item cannot accept the change. For example, technician mode on a computer that is not Windows.
429 Too Many Requests
Each method and route has its own rate limit, shared by all API keys in your organization. Wait for the number of seconds in the Retry-After response header, then retry the request. The current limits are in the Partner API reference.
A computer change has not taken effect
Technician mode, elevation mode, and agent uninstall changes apply at the agent's next configuration check-in, so they are not immediate. While technician mode is on, the API shows technician mode instead of the computer's elevation mode. An elevation mode change shows only after technician mode ends.
Advanced Use Cases
Custom Reporting
Use the Partner API to collect operational data and build dashboards tailored to your organization.
Automation Workflows
Automate business processes by integrating AutoElevate data with RMM platforms, ticketing systems, internal databases, and reporting tools.
Compliance and Audit Reporting
Organizations can use API-accessible data to support internal reporting, compliance reviews, and operational visibility initiatives.
Partner API vs PSA Integrations
When to Use PSA Integrations
Use the dedicated integration guides if you are connecting AutoElevate with a supported PSA platform such as:
- Halo PSA
- ConnectWise Manage
- Zendesk
These integrations are pre-built and include product-specific configuration guidance.
When to Use the Partner API
Use the Partner API when:
- Building a custom integration
- Integrating with an unsupported platform
- Creating internal automation
- Developing custom reporting solutions
- Accessing AutoElevate data programmatically
Best Practices
Follow Official API Documentation
The Partner API documentation should always be considered the authoritative source for endpoint behavior, request formats, and authentication specifications.
Test Changes Before Production Deployment
Validate integration updates and authentication changes in a testing environment before deployment.
Monitor Authentication Failures
Unexpected authentication failures often indicate:
- Expired credentials
- Invalid signatures
- Missing body hash values
- Permission changes
Detecting these issues early can reduce downtime.
Document Your Integrations
Maintain internal documentation that records:
- API key ownership
- Integration purpose
- Contact information
- Rotation schedules
- Dependencies