Connectors / Service / Guardian



Guardian is a life insurance company.


Guardian provides individual life insurance as well as investment management and disability and retirement planning, among other types of insurance for individuals.

Connecting to your Guardian instance

To allow to connect to your Guardian connector, you'll need to white list ALL of the following static IP addresses for access:



Within the workflow builder, highlight the Guardian connector.

In the Guardian connector properties panel to the right of the builder, click on the Authenticate tab and the 'New authentication' button. This will result in a authentication pop-up modal.

This will result in a authentication pop-up modal. The first page will ask you to name your authentication and select the type of authentication you wish to create ('Personal' or 'Organisational').

The next page asks you for your 'API Key', 'Secret', and 'Subject' credentials.

Once you have added these fields to your authentication pop-up window, click the 'Create authentication' button.

Go back to your settings authentication field (within the workflow builder properties panel), and select the recently added authentication from the drop-down options now available.

Your connector authentication setup should now be complete.

Available Operations

The examples below show one or two of the available connector operations in use.

Please see the Full Operations Reference at the end of this page for details on all available operations for this connector.

Using the Raw HTTP Request ('Universal Operation')

As of version 1.0, you can effectively create your own operations.

This is a very powerful feature which you can put to use when there is an endpoint which is not used by any of our operations.

To use this, you will first of all need to research the endpoint in the Guardian API documentation, to find the exact format that Guardian will be expecting the endpoint to be passed in.

Note that you will only need to add the suffix to the endpoint, as the base URL will be automatically set (the base URL is picked up from the value you entered when you created your authentication).

The possible base URL for Guardian are:

  • Development server:
  • Test server:
  • Production server:

For example, say that the Get compute status operation did not exist in our Guardian connector, and you wanted to use this endpoint. You would use the Guardian API docs to find the relevant endpoint - which in this case is a GET request called: /computestatus.

As you can see, the API call accepts a single mandatory query parameter 'group_policy_id'. You should provide value for this parameter while executing the API call.

So if you know what your method, endpoint, and details of your query parameters are, you can get the compute status information with the following settings:

Method: GET


Query Parameter: Key: group_policy_id Value: 17xx98

Final outcome being:

Example Usage

TRAY POTENTIAL: is extremely flexible. By design there is no fixed way of working with it - you can pull whatever data you need from other services and work with it using our core and helper connectors. This demo which follows shows only one possible way of working with and the Guardian connector. Once you've finished working through this example please see our Introduction to working with data and jsonpaths page and Data Guide for more details.
PLEASE NOTE: In these examples, we show data being received via the [Webhook trigger]( - i.e. a scenario whereby you have configured an external service to automatically send new record data to your workflow. In practice, you can receive data in any structure, and in other ways, such as from any pre-built service trigger or from a previous workflow step that has pulled data from another source (e.g., Salesforce 'Find Records', CSV Reader, etc.)

Store policy specifications in a database

Below is an example of a way in which you could potentially use the Guardian connector to get the policy specifications using the get policy specs operation.

These specifications, in the end, are stored in a third-party service. In this case, we are using Google sheets as a generic placeholder for any service or database you may wish to use.

EXTRA AUTHS: In order to complete this workflow, you will also need to be authenticated with the Google Sheets connector.

The following workflow gives an example of how you can achieve this:

  1. Setup using a trigger to Fetch the Policy IDs.

    The Group Policy IDs received through the trigger are in JSON format:

    "group_id": [
  2. Loop Policy IDs is the loop set to 'Loop List' the Policy IDs received from the trigger.

    A jsonpath for the 'List' field should appear similar to this: $.steps.trigger.body.group_id. You can always use a connector-snake to find the jsonpath.

    JSONPATHS: For more information on what jsonpaths are and how to use jsonpaths with, please see our Intro page and Data Guide for more details.
    CONNECTOR-SNAKE: The simplest and easiest way to generate your jsonpaths is to use our feature called the Connector-snake. Please see the main page for more details.
  3. Get Policy Specs is a Guardian connector's operation that gets the specifications for the specified group policy ID.

    The 'Group policy ID' field accpest jsonpath ($.steps.loop-1.value) from the Loop Policy IDs step.

    The specifications fetched for any policy would look similar to this:

    Click on the Debug tab to view Input and Output for individual steps.

  4. Store Policy Specs stores selected details of each policy in a data storage. In this case, a Google sheet.

    The successfuly populated Google sheet should look similar to this:

Send policy specification via email

Along with storing data fetched from the Guardian connector as demonstrated in the above example, you can also send automated emails to the Guardian customers.

In this example, we are sending a confirmation email to the Guardian customers informing them about the successful registration of their opted policy.

The email sent would look like this:

The following workflow gives an example of how you can achieve this:

Similar to the previous workflow, once you have set up a trigger to Fetch the Policy IDs, then Loop those Policy IDs, and Get the Policy Specs for the received policy IDs.

The next steps are as follows:

  1. Fetch Key/Value pairs is an Object Helpers step that will add key/value pairs from the source, i.e., policy specifications received from the Get Policy Specs step.

    Based on the final email shared above the 'Add key/value pairs' operation fetches value for the following attributes:

    The fetched key/value pairs would look like this:

    These values will be used further to send a confirmation email.

  1. Store data stores the values received from the previous step under the specified email key in a Data Storage using the 'Append to list' operation.

  2. Get data gets the values set under the email key in the previous step.

  3. Loop data loops through the data from the get data step.

  4. Send email sends an email to the specified address. The 'Content' of an email contains jsonpaths for the attributes from the previous step.

The jsonpaths are specified in interpolated mode, i.e., wrapping the jsonpaths in curly brackets:

Hi {$.steps.loop-2.value.bill_group_name}, we, {$.steps.loop-2.value.sender_name},
are pleased to inform you that the plan ({$.steps.loop-2.value.plan_name})
you have opted for will be effective from {$.steps.loop-2.value.plan_effective_Date}.
INTERPOLATION: When you wish to include JSON generated data within another input/ output/ result, use our Interpolation method as described here.