On this page

Configure an API action inside a supported form or booking workflow to send mapped data to an external HTTP endpoint and handle its response. The separate API Actions resource is hidden and has no standalone configuration form.

Use Cases

Start at the API action, follow the rejected-request correction, and compare the saved entry with the receiving receipt.

Map form fields into a tested API action Watch on YouTube from 02:04

API Actions can be used for a variety of purposes, such as:

  • Sending data to a CRM: When a new user registers, you can use an API Action to send their information to your CRM.
  • Processing payments: Integrate with a payment gateway to process payments from your users.
  • Sending notifications: Send notifications to your users through a third-party service like Slack or Telegram.
  • Retrieving data: Fetch data from an external service and display it in your application.

Configuration

When configuring an API Action node in the workflow builder, you will need to provide:

  • Endpoint URL: The full URL of the external service (e.g., https://api.crm.com/v1/leads).
  • HTTP Method: GET, POST, PUT, PATCH, or DELETE.
  • Bearer Token: (Optional) The authentication token if the API requires Bearer auth.
  • Custom Headers: Any additional headers required by the API (e.g., X-Custom-Header: value).

Using Constants

To keep your keys secure and your workflows maintainable, you can use Constants in your API configuration. Constants allow you to replace sensitive values or repeating strings with a placeholder like {{MY_CONSTANT}}.

Supported fields for constant substitution:

  • Endpoint URL: e.g., https://api.example.com/v1?key={{API_KEY}}
  • Bearer Token: e.g., {{CRM_TOKEN}}
  • Custom Headers: e.g., Key: X-Client-ID, Value: {{CLIENT_ID}}

When the workflow runs, the system automatically fetches the secure value from your Constants and replaces the placeholder before making the request.

If the node offers Test URL, configure an explicit controlled endpoint and verify which execution path uses it. A normal workflow run can call the production URL. Design write operations to tolerate retries without creating duplicate records.

Data Payload

You can dynamically construct the data sent to the API using two methods:

1. Fields Mapping

Map data from your internal system to the keys expected by the external API.

  • Key: The field name expected by the external API.
  • Value: The path to the data in the Nviti model (e.g., visitor.email, data.custom_field, metadata.source).

2. Append Data

Add non-sensitive static data, such as a fixed source label, to each request. Keep credentials in protected authentication configuration or Secret constants.

  • Key: Static field name.
  • Value: Static value.

Response Handling & AI Integration

The system can intelligently handle the API response to interact with the user in the chat.

Direct Chat Response

If your API returns a JSON object with a chat_message key, its value will be immediately sent to the user as a message from the assistant.

Example API Response:

json
{
  "status": "success",
  "chat_message": "Thank you! Your ticket #12345 has been created."
}

AI-Interpreted Response

If you enable "Send Response to User" but the API does not return a chat_message field, the system will use AI to interpret the raw JSON response.

  1. The system converts the JSON response into a simplified format.
  2. The AI Assistant analyzes this data along with its persona and instructions.
  3. The Assistant generates a natural language response explaining the API result to the user.

This allows you to connect to complex APIs without needing them to return pre-formatted chat messages.

Check a request before relying on the workflow

Use Test Endpoint to send generated sample values. An optional Test URL overrides the configured endpoint for this check; leaving it blank uses the endpoint URL. The payload preview supports nested destination keys, and date/time fields use appropriately formatted sample values. Review the HTTP status and response body, including rejection responses.

An accepted sample request does not prove that a form submission triggers the workflow. Save and activate the connected workflow, submit a fresh test entry, and compare its values with the receiving service's actual receipt. Keep sample requests separate from customer submissions, and make the receiving service handle repeated requests appropriately.