Trigger Workflow via API
Last updated
Last updated
Nected enables you to securely trigger your workflow from your systems via API for which you can choose to have private authentication using an authentication key.
Note: All production workflows must be run securely using an API, but you can choose to run a staging workflow either using an API or directly on the Nected platform.
Follow this procedure to trigger a workflow using an API:
Before calling the workflow, first, you need to test it.
Click on the Trigger Node, and then go to the settings tab to access the API settings:
In the settings tab, there are two options: API and WebHook. Choose the option API (by default API is selected).
Use the information on the API settings window to trigger the API using an API platform of your choice, for example Postman.
The following list describes the options on the API settings window for a workflow:
Authentication – The authentication method for the API. You can either select None (no authentication required) or Private (use an authentication key to trigger the API).
Response Cache - This allows you to boost performance by retrieving cached data for specified inputs rather than re-fetching it from external APIs or databases.
Base URL – The base URL for the workflow.
Body Params – Body parameters that you can use to run the API.
environment: The default environment is production. You can set up different values based on which workflow you want to test in which environment.
Testing an Unpublished/Draft Workflow in Staging: If you wish to test an unpublished or draft workflow in the staging environment, you can use the API for testing purposes. To do this, set environment: Staging
in the Body Parameters. This allows you to evaluate the workflow's behavior and functionality before publishing it.
Running a Published Workflow in Production: When you are ready to execute a workflow in a live, real-time production environment, you need to trigger the API with environment: production
. This action will activate the workflow for real-time decision-making. If you don't pass any environment, it will automatically pick up the production instance.
params: These are defined in "Add Source" to be passed along to the API. You can copy this from the API Settings page and integrate it into your frontend/backend or any 3rd party apps via HTTP call.
Version: The version of the workflow is mentioned in the API body if the environment is in production. If the environment is staging, there will be no version added to the API body.
The default environment is production.
By following these steps and utilizing Nected's API, you can seamlessly integrate your rules with your chosen database, allowing you to make data-driven decisions effortlessly.
Well, as we've multi-environment along with multiple versions, it can be confusing for you while working with the API. To minimize your confusion, here is a table clarifying the API behavior based on versions and different environments:
✅
✅
"version":"version_value",
"environment":"env_value", (staging/production)
If in your API body, both are written, then simply that specific version of workflow will be executed
✅
❌
"version":"version_value",
"environment":"production",
While calling the API, in the body, if you've not specified the env
but you've specified the version
then the by default the production
environment will be called of that version.
❌
✅
"version":"latest",
"environment":"env_value", (staging/production)
So, if you've not specified the version but the env
then the API will call the latest version of the workflow of the environment that you've specified i.e. either staging or production.
❌
❌
"version":"latest",
"environment":"production",
If you've not specified anything in your API body, then by default the latest live/production version of the workflow will be called and executed.
This is how the API body works, so if you're triggering the workflow via API, make sure you follow this and call the API accordingly.
Similar to rules, workflows in Nected can also benefit from Response Caching to enhance performance by utilizing cached responses for specified input parameters during execution.
Selecting the Trigger Node: Click on the trigger node within your workflow configuration.
Accessing Trigger Settings: Within the trigger configuration panel, navigate to the Settings tab.
Enabling Response Caching: Locate and toggle the response caching option in the API Settings.
Configuring Caching Parameters:
Key Parameters: Specify input parameters for which cached data should be used.
Cache Expiry Time: Define how long the data remains cached before being refreshed.
Clear Cache: Click on the dropdown button to select the environment for which you want to clear the cache. This is to clear cached data for:
Staging Environment: Removes all cached data for staging instances.
Production Environment: Clears cache for production environments, ensuring fresh data retrieval when necessary.