Partner API (BETA)
Programmatic access to AutoElevate data for integration partners
Written by Daniel Rivera
Updated at August 18th, 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 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 provides access to supported AutoElevate resources.
Available API resources may include:
- Computers
- Elevated Sessions
- Audit Logs
- Additional platform resources documented in the API specification
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.
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
Click to Zoom (screenshot of the user type selection to be added)
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 API Key
- Configure the key:
- Name — a label that identifies the integration using the key
- Type — choose the authentication scheme (see the Partner API reference for how each scheme is used)
- Permissions — 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
- Expiration — prefer the shortest expiration that works for your use case
- Click Generate and copy the key secret(s) immediately — they are shown once and cannot be retrieved again
Click to Zoom (screenshots of the Users screen and API Key dialog to be added)
Authentication and Request Signing
All Partner API requests must be authenticated using a valid AutoElevate API key and signed using the AE-HMAC-SHA256 authentication method.
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
Audit Log-related endpoints have historically been a common example of this behavior.
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.
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
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