> ## Documentation Index
> Fetch the complete documentation index at: https://dialnexa.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Use Custom Function Nodes In DialNexa Workflows
> Call a public HTTP API from a DialNexa workflow with custom function nodes, templates, response variables, and success or failure branches.
Custom Function nodes let a DialNexa workflow call a public HTTP API and route the lead based on the response. Configure the request, map response values into lead variables, and connect both Success and Failure outputs before activating the workflow.
## When To Use Custom Function Nodes
Use a Custom Function node when a workflow must read or update a system that is not available as a connected DialNexa integration. Examples include checking eligibility, creating a record in an internal application that has a public API, or fetching a value used by a later Conditional node.
Use an [Application node](/docs/workflows/application-nodes) when DialNexa already provides the required connected integration action.
## Before You Begin
* Prepare a public `http` or `https` endpoint. Localhost, private network, and other non-public addresses are blocked.
* Decide which lead variables the request needs and add workflow fallback values for required variables that no earlier node creates.
* Decide which response values later nodes need.
* Design separate Success and Failure paths.
* Avoid placing credentials in the URL. Send authentication through request headers.
## Configure The Request
| Setting | Supported value |
| ------------------ | ----------------------------------------------------------------- |
| Function name | A readable name used in the builder and execution evidence. |
| Endpoint | A public `http` or `https` URL without embedded credentials. |
| Method | `GET`, `POST`, `PUT`, `PATCH`, or `DELETE`. |
| Headers | Key-value request headers. |
| Query parameters | Key-value URL query parameters. |
| JSON body | A valid JSON body for methods other than `GET`. |
| Timeout | 1,000 to 30,000 milliseconds. The default is 10,000 milliseconds. |
| Response variables | A lead-variable key and a response path for each value to store. |
| Outputs | One destination for Success and one for Failure. |
Request URLs, headers, query parameters, and body values can reference lead variables with `{{variable_name}}`. In JSON values, use `{{json variable_name}}` when the inserted value must remain a JSON number, boolean, object, array, or `null` instead of becoming a string.
## Map Response Variables
Each response-variable row has a key and a path. The key becomes a lead dynamic variable. The path selects a value from the response body.
| Response body | Path | Stored result |
| ------------------------------------ | --------------- | ---------------------------- |
| `{ "customer": { "tier": "gold" } }` | `customer.tier` | `gold` |
| `{ "items": [{ "id": 42 }] }` | `items[0].id` | `42` |
| Any complete JSON response | `$` | The complete response value. |
Objects and arrays are stored as JSON text. A missing or `null` path becomes an empty value. Later nodes can reference the stored key through their normal lead-variable controls.
## Build A Safe Success And Failure Flow
Drag a Custom Function node onto the workflow canvas and give it a clear function name.
Select the HTTP method, enter the public endpoint, and add the required headers, query parameters, and JSON body.
Map only the response values that later nodes need. Use dot paths or array indexes to select nested values.
Send Success to the normal next step. Send Failure to a retry, wait, notification, or intentional terminal path.
Add fallback values for required lead variables unless an earlier Custom Function node produces them on every path.
Run a controlled test, then inspect lead history and invocation evidence before adding production leads.
## Request And Response Limits
* HTTP status codes from `200` through `299` use the Success output. Other status codes and request errors use Failure.
* A response body can be at most 512 KiB.
* DialNexa follows at most three redirects.
* Authentication, API key, token, secret, and cookie headers are removed before a cross-origin redirect.
* Each redirect target is checked again and must resolve to a public address.
* Request and response evidence is recorded with sensitive values redacted where supported.
## Verify The Result
Open the workflow lead history and confirm the node followed the expected output. Review the HTTP status, latency, invocation ID, and stored response-variable keys. Then inspect the next Conditional, Call, or Application node to confirm it received the expected values.
## Troubleshooting
Use a public HTTP or HTTPS URL. Remove embedded credentials and confirm DNS does not resolve to localhost, private, link-local, or another non-public address.
Add the lead variable to the uploaded lead, create it in an earlier Custom Function node, or configure a workflow fallback value.
Compare the configured path with the actual JSON response. Check property spelling, array indexes, and whether the endpoint returned an empty or `null` value.
Confirm the endpoint returned a `2xx` status within the timeout and that its response stayed below the size limit.
## Related Pages
Understand nodes, edges, configs, and outputs.
Supply request values and fallback data.
Review execution and branch evidence.
Use connected integration actions.