CX Actions: API Requests in Zingtree

Overview

CX Actions allow you to connect Zingtree to any publicly available API or third-party service.

CX Actions make it possible to:

  • Create a Data Source to define API authentication and token management.
  • Build a Connected Object (endpoint) to perform valid CRUD (Create, Read, Update, Delete) operations against a RESTful API.

The primary goal is to provide re-usable, scalable resources that connect your workflows to external data sources.

Get CX Actions

Do you want access to this new feature? Contact your Zingtree Account Manager or our Support Team.

From the Apps & Integrations tab, you can define one Data Source and one Endpoint, and reuse them across multiple workflows and trees.

1.png
 

Core Features

  1. Data Source (Authentication)
    • Defines how to connect to your API.
    • Supported Authentication types include:
      • API Key
      • Basic Auth
      • Bearer Token
      • JWT Bearer
      • OAuth2 Password Credentials
      • OAuth2 Client Credentials
  2. Connected Object (Endpoint & Request Configuration)
    • Defines the endpoint and how requests will be sent.
    • Supports CRUD operations.

Data Source Types

Zingtree supports the following connectors out of the box:

  1. Salesforce Connector
    • Uses your Salesforce credentials.
    • All objects (including custom objects) will be available for CRUD operations.
  2. Universal Connector (HTTP Connector)
    • Connects to any API endpoint using supported authentication methods.

Example: Data Source Selection

2.png

Creating a Data Source

To create a Data Source:

  1. Identify API Documentation
  2. Determine Authentication Type (from the list above)
  3. Gather Authentication Credentials (client ID, client secret, etc.)
  4. Configure the Data Source in Zingtree

Data Source Setup Screen

3.png

💡 Tip: When using OAuth2, ensure the expiration time is set correctly to avoid authentication failures.

 

Creating a Connected Object

Once a Data Source is configured, you can create Connected Objects to interact with API endpoints.

  • Supported HTTP Methods: GET, POST, PUT, PATCH, DELETE
  • Optional information: Headers, Parameters, Payload

Connected Object Configuration Example

4.png

💡 Tip: Use environment variables or Zingtree variables in payloads to make requests dynamic and reusable across workflows.

 

How it Works (3-Step Flow)

  1. Connect External Data Source
    • Choose authentication method and provide credentials.
  2. Create Connected Object
    • Configure endpoints and HTTP method.
    • Add headers, parameters, or payloads if needed.
  3. Use Data Connected Node in Workflows
    • Reference static or dynamic values in your workflow nodes.

Important: Variable names will be passed into the Connected Object automatically, provided that the variable names in both the workflow (session) and the Connected Object are the exact same.

Visual Workflow

Create a node & select Data Connected Node

Accessing Response Metadata

Every Actions API response in our system is decorated with a special metadata key named _zt_meta. This allows you to access technical details about the API request directly within the response variable, alongside your actual data.

This is particularly useful for building logic branches based on the success or failure of a call (e.g., distinguishing between a 200 OK and a 404 Not Found).

Available Metadata Fields

The _zt_meta object currently provides the following information:

  • response.code (Integer): The HTTP status code returned by the API (e.g., 200, 404, 500).

  • response.body (String): The raw response body, only set when there is a request error (non-2xx response).

The Metadata Structure

The metadata object is automatically injected at the root of your action variable:

"_zt_meta": { "response": { "code": 200 } }

How to use it in Logic

You can reference the status code in Logic Nodes, Expression Nodes, or Scripts using standard dot notation:

  • Syntax: actions.[alias]._zt_meta.response.code

  • Example: actions.get_products._zt_meta.response.code

Important Note on Key Collisions

Because _zt_meta is injected directly into your response payload, please ensure your upstream API does not use _zt_meta as a key. If the external API returns a key with this exact name, it may be overwritten by the system metadata.

API Response Structure & Object Wrapping

To ensure consistent access to response data and metadata, our system requires that all API responses be formatted as a JSON Object at the root level.

However, we recognize that many external APIs return Lists (Arrays) or simple values (Strings/Integers) as their root response. To support these endpoints without errors, we automatically apply a standard wrapper to any response that is not already an object.

How it works

When your Action receives a response:

  1. If the Root is an Object: The data is passed through as-is.

  2. If the Root is an Array or Primitive: We wrap the data inside a parent object using the key value.

Examples

Scenario A: The API returns an Object (No change) If the external API returns a standard object, your variable structure remains exactly as the API sent it.

  • Raw API Response: {"id": 123, "name": "Alice"}

  • Variable Access: actions.get_user.name returns "Alice"

Scenario B: The API returns an Array (Wrapped) If the external API returns a list, we wrap it and you must include .value in your path to access the array.

  • Raw API Response: [{"id": 1}, {"id": 2}]

  • System Transformation:

    { "value": [{"id": 1}, {"id": 2}], "_zt_meta": { ... } }

  • Variable Access:

    • actions.get_list.value[0].id returns 1

    • Incorrect: actions.get_list[0].id (This will error because the root is now an object)

Scenario C: The API returns a Primitive (Wrapped)

  • Raw API Response: "Success"

  • System Transformation:

    { "value": "Success", "_zt_meta": { ... } }

  • Variable Access: actions.get_status.value returns "Success"

7.png

Use the Connected Object in the Data Connected Node

White Listing

In order to whitelist Zingtree API Requests to your own APIs, you can expect all requests from Zingtree to come from the following Static IPs:

  • 54.85.52.170/32
  • 52.0.160.217/32
  • 3.233.140.192/32

Limitations

  • The base domain must be a valid domain URL (no IP addresses).
  • Zingtree does not support XML.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Didn't find what you need?

Our friendly customer support team is here to help

Submit a Request

Looking for help or advice?

Reach out to our knowledgeable community of users.

Zingtree Community