With over 30 000 SaaS applications out there, plus your own on-premise apps and custom builds, no IPaaS solution will ever have all the connectors you need. This means that custom connectivity is always critical for successful automation across the enterprise.
However, custom connectivity comes with risks, especially if you handle sensitive customer data. A connector that you can use to send data anywhere could potentially be used to send your sensitive data…well, anywhere. Therefore, to be able to usefully adopt custom connectivity, you also need to build in guardrails and security controls.
Creating guardrails for custom connectivity
Let’s consider an example: your organization has purchased a custom natural language processing (NLP) service that you’ll use to analyze raw customer communications for sentiment and intent. You need to enable your CS builders to connect to the service and work it into your automations.
Worakto’s HTTP connector is a simple way to connect to any HTTP API without having to go through the process of building a custom connector from scratch. However, you don’t want to give builders the ability to send your sensitive customer data to any HTTP API, only to your new NLP service. You can easily accomplish this by creating a connection with a predefined base URL, and setting appropriate user permissions with role-based access.
How to do it
Set user permissions
When handling sensitive customer data, you need to make sure that your teams have appropriate permissions. In Workato, you can control the ability to create and delete connections. A best practice is to give the ability to manage connections only to a small number of users responsible for working with your vendors and partners.
Your line-of-business builders, on the other hand, can have complete freedom to build recipes. However, they can only use apps and connections approved and created by your connection admins.Â
This approach prevents builders from sending your data anywhere you don’t want it to go.
Create HTTP Connection
Your connection admin can create a new connection to the HTTP Connector app in workato. As part of the connection, they specify a base URL. For example: https://api.nlpservice.com/v1Â
Once you specify a base URL, the connection can only be used to connect to endpoints beginning with that URL.
Build recipes
Your line-of-business builders can now use this connection in their recipes. When they create an action in the HTTP connector, the builder specifies only the relative path of the API endpoint they need to connect to.Â
The builder can only use the predefined base URL. Because they can’t create new connections, the builder cannot, whether intentionally or accidentally, send sensitive data to an unapproved service.
Easy lifecycle management
As an added bonus, if you use recipe lifecycle management to migrate recipes between development, testing and production environments, specifying a base URL in your connections makes recipes easier to move between environments. For example, you can easily specify the base URL for your sandbox instances in your DEV environment, and your production instance in your PROD environment.
The relative paths of API endpoints are much less likely to change. This means you can deploy your automations to production without changing the recipes themselves.
Pro tip: HTTP or custom connector?
A quick, light-weight setup makes the HTTP Connector a great fit for an app or service that you need to include occasionally in your automations. For a service that’s core to your automation projects, think about creating a custom connector with the Connector SDK. A custom connector takes a little more time to create, but is even easier for recipe builders to adopt. A custom connector allows your business users to interact with a service in plain, business-oriented language. No understanding of APIs required.
The post How to use custom API calls securely appeared first on Workato Product Hub.
Read MoreWorkato Product Hub