Alteryx Server Ideas

During a recent project, I explored the Alteryx Server Download a Workflow Package API Endpoint, which includes an optional versionId parameter. The documentation suggests that this parameter should allow users to retrieve specific, prior versions of a workflow package by supplying the appropriate version ID. However, in practice, I found that regardless of which valid prior version ID was provided, the API always returned the current published version of the workflow.

This behavior presented a challenge for our automation use case, where we aimed to implement version control and retrieval solely through Alteryx Server, rather than relying on external tools like Git. After thorough testing and validation, I shared these findings with Zach Hamilton and Marty Moravec at Inspire 2025, who were able to confirm the behavior.

I appreciate the continued enhancements and support the Alteryx team provides for the Server platform and its APIs. Resolving this issue would greatly benefit users who depend on robust version management and automation capabilities within Alteryx Server. Thank you for considering this feedback, and I look forward to future improvements in this area.

The current Enterprise Utility Workflow does not have a match/look-up in place between the two environments for user ID's.  Thus, the migration workflow doesn't work without adding in a couple extra API calls.  When we upgrade to a new version of the utility, I have to add this back in. 

It would be nice if the workflow would come with this already configured.

You cannot currently upload a new workflow and specify your own workflow_id GUID.  This would be useful for systematic workflows that need to be referenced in code.  Currently, you either to search for a workflow by name, but you are not guaranteed it a workflow instance you uploaded.  This would be helpful for server and workflow administration.

Given there are multiple api versions.  I need a way to call the api and get the server version so I can make the correct API call or construct code logic which provides the user code requirement based on the versions features or limitations.

I propose a api call ../getserverinfo/ that returns server metadata like version, default worker thread count, and default memory allocation.

There is currently not a way to call the API and find out the calling user.  For instance, if I have a user API key and secret, I  to return the rest of the user info for the calling user or who is calling the api.  I propose a api call like ../user/whoami