What is the Alteryx Server API? A Salesforce Use Case

by James Charnley

Note: This blog assumes an existing base level understanding of what APIs are. If you’d be interested in more of an introduction to APIs blog, please let me know.

An Alteryx server can be an incredibly valuable tool regarding the scheduling, governance and sharing of Alteryx workflows, and we can take further steps towards automation or control in certain cases by leveraging the power of the Alteryx Server API. A couple of quick examples of how we could do so are:

• Admins automating creation of collections, adding users or managing permissions.

• Users are able to download a workflow package or workflow records from the v3 workflows endpoint.

• Users using the v2 jobs endpoint to create a job and add it to the execution queue.

For those wanting a hands-on example, we’ll go over an example of a use case for the aforementioned jobs endpoint later in the blog.

It’s worth mentioning now that to use this API, you will either need a Curator role on your server, in which case you can access all six available APIs, or for an admin to have granted API access to your user profile so you can access the Subscription, User v2 and User v3 APIs. Considering admins will likely know most of what this blog contains already, this blog has a focus on the user APIs, since even if you don’t have adequate permissions currently, being aware of the API’s capabilities could still prove useful.

For a full list of endpoints available to admins or users, check out this useful resource on Alteryx’s official website by clicking on this link.

So how do we create a request?

The following will be examples of how we can interact with the Alteryx Server API via Alteryx itself, but note that any application that can submit a request to the relevant URL could be used. At the highest level, interacting with an endpoint in Alteryx (or otherwise) will generally follow this pattern:

For a v1 or v2 endpoint, a workflow in Alteryx using the v2 jobs endpoint to add a job to the execution queue therefore might look something like this:

For a v3 endpoint it could look the same, but additionally there’s a nifty macro pack designed for interacting with the v3 API that can be downloaded from this link. This makes life easier as a developer to configure the request, but the general premise remains the same. An example of a GET request for all collections could therefore be as simple as:

A Use Case

I was recently asked to deliver a proof of concept for a client considering investing in an Alteryx Server that if they wanted, a workflow could be automatically run on their server every time that the Account table was updated in Salesforce. For what it’s worth, Alteryx Server does not currently have webhooks, so this request was restricted to using the API. 

We’ve established that triggering a workflow to run remotely is fairly straightforward thanks to the v2 jobs endpoint, so despite the fact that I’m no Salesforce expert, after a little bit of research, the logic seemed to be:

I wanted to start at the end of the process, proving that a script written in Salesforce can send a POST request. In Salesforce, this would be an Apex Class. I’d never written any Apex before, but after some trial and error in the Salesforce developer console (and some serious consulting from our friend Google) I eventually came up with something that worked.

Without getting too bogged down in the syntax, the logic of configuring headers and payload remains the same as if we were in Alteryx, we just have to write it down instead of ticking boxes in the download tool. If this script is run in Salesforce, the request is sent to our URL, and the workflow is added to the job queue.

(Note that in production, we’d need an extra piece of the script to authenticate first, and dynamically add the token to the Authorization header, rather than just grabbing a working Bearer token, but this sufficed for a time-sensitive proof of concept.)

Once that Class was working, I needed an Apex Trigger. This is essentially a custom action for something to occur before or after changes to a Salesforce record. This one (pictured below) quite simply says every time that the Account table is updated, run the Class script that I just wrote (called AlteryxServer2, because how hard is it to get something right the first time?).

With these scripts in place, the proof of concept was complete, and we have a use case for something that wouldn’t have been possible without the API!

If you have access to an Alteryx Server, or your company is considering one, then hopefully after reading you’re at least thinking about going to check out all available endpoints to see how it might be able to benefit you! Thanks for taking the time to read, let me know if you find any good new use cases!