API
26
VOTE
Expose Structured TestRail Test Data in Aha! Develop for Reporting and Traceability
What is the challenge?
The TestRail integration displays test data within Aha! Develop but does not expose it as structured, reportable fields. Attributes like Test Case ID, Test Status, Execution Result, and Coverage render as a display only bl...
Likely to implement
5
VOTE
Position parameter for REST API
What is the challenge? The API has no way to set a page or folder's position within the table of contents tree. parent_id controls nesting, but not order among siblings. Reordering only works by manually dragging in the UI.
What is the impact? Te...
Future consideration
6
VOTE
Support creation of paid seat groups via API
What is the challenge?
Admins who manage users and provisioning programmatically can work with many account settings through the API, but they cannot create paid seat groups there.
This forces teams to leave automated provisioning workflows an...
Future consideration
11
VOTE
Add granular scoping controls for API keys
What is the challenge?
API keys inherit the full permissions of the user who creates them, and there does not appear to be a way to scope the key itself to specific workspaces, folders, or record types.
This creates concern internally when bui...
Future consideration
38
VOTE
Provide Microsoft Power Automate Connector
What is the challenge?
Easily integrating with Aha! using Microsoft integration platforms
What is the impact?
Having to rekey data - costs time
Describe your idea
Microsoft provides a low-code multi-platform integration service calle...
Future consideration
2
VOTE
Please fix the published OpenAPI spec to declare the query parameters the API supports
We build spec‑driven integrations against the Aha! REST API (OpenAPI codegen, LLM tool frameworks). These clients can only send parameters the published openapi.json declares. The gap is API‑wide, not endpoint‑specific: the spec omits query param...
Likely to implement
9
VOTE
2
VOTE
Enhance the Audit History API to provide complete user information for both custom User-type fields and system User-type fields. For custom User-type fields, in addition to the existing raw_value (user IDs), expose the corresponding user email addresses (similar to the email_value field returned by the entity retrieval APIs). This would eliminate the need for additional user lookup API calls and keep the Audit History API consistent with the entity retrieval APIs. For system User-type fields (such as Assigned To, Created By, etc.), enhance the Audit History API to expose the underlying user identifiers and email addresses, rather than only the display names. Providing user IDs and email values would enable reliable processing of audit records, avoid ambiguities caused by duplicate display names, and offer a consistent experience across all User-type fields. These enhancements would improve API consistency, reduce integration complexity, and make audit history processing more reliable for customers integrating with Aha!.
What is the challenge? The Audit History API currently provides limited information for User-type fields. For custom User-type fields, it exposes only the user IDs (raw_value) without the corresponding email addresses. For system User-type fields ...
Future consideration
6
VOTE
Expand payload response in "Assistant usage API" endpoint
What is the challenge?
Using the "Assistant usage API" endpoint to extract usage of the AI assistant into a 3rd party database, to be used to create a usage dashboard. There are certain data points not present in the response payload, which is m...
Future consideration
10
VOTE
Create an API end point for subscription details
What is the challenge? Aha! does not have an API end point that provides subscription details - plan type, number of seats. What is the impact? Teams would like the ability to programmatically call for subscription details to keep subscription det...
Future consideration
© 2026 Aha! Labs Inc.•All rights reserved