If you've dug around into the built-in Workato actions like Loggers and Variables, you might have seen the action for HTTP Requests. While Workato comes pre-loaded with hundreds of out-of-the-box actions and triggers, you might find yourself using a system that Workato doesn't have a well defined connector for.
Lets take a simple example with Quick Base. Workato handles most major functions that a Quick Base / Workato developer might need. It handles most CRUD actions in any table, file handling capabilities - and has extremely powerful query abilities. But the Quick Base API is much broader than that. There are also User Management and Schema level capabilities at your disposal depending on what you're doing. While these are not built in features to Workato - that doesn't mean Workato doesn't have a solution.
Enter the HTTP Connector. With this method - you can enter any API call to any system that accepts HTTP Requests. You can do any GET, POST, PUT, DELETE, HEAD, PATCH, sent as XML, JSON, Text, Binary. This means that if you can find the API documentation for your cloud system - you're almost guaranteed to be able to integrate it with Workato and HTTP. In order to use the HTTP connector - you only have to select 'HTTP' from your 'Actions' dropdown. From there - you can select your method, and start configuring your request as needed. For more detail about what has to actually go into your HTTP request - you'll need to review and understand the API documents for your intended system/endpoints
So when would you use this method?
Now - keep in mind that when doing it this way - you lose a little bit of functionality that Workato normals builds in for you.
In keeping with the Quick Base Example - lets say you want to use Workato to automatically invite users. Out of the box - Workato doesn't have a built in action for provisioning Quick Base users - API_ProvisionUser. Quick Base will happily accept a GET request for that particular action though - so we turn to using the HTTP action. One requirement of all Quick Base API calls though, is authentication. Normally - when you set up your Workato connector - you take care of that - and these connectors help handle the authentication for you when you use one of their built-in actions. This is what happens when you set up a new App Connection. Workato is getting you all set up so that you don't have to worry about dealing with your user name and password every time. But with HTTP - since you're not actually using one of your Authenticated connectors - you have to find a workaround. So for this example - you would need to make another HTTP request, this time to do an API_Authenticate to get a temporary ticket, then make your ProvisionUser call.
So while HTTP makes your integration capabilities infinitely more powerful - they also take a bit more thought into all the different implications that go into using this type of connector.
While we've only focused in this article on Sending HTTP requests - Workato can also receive requests. Check back soon for an article related to Workato and Receiving HTTP Requests.
If you're interested in learning about the more advanced developer centric capabilities Workato offers similar to HTTP - check out this article on Custom Connectors using the Workato SDK.