The API Request Block allows you to make API calls within a dataflow. You can configure it by specifying the HTTP method, API endpoint, headers, query, body, and path parameters. The methods supported are GET, POST, PUT, DELETE, and PATCH.

Example Scenario

Requirement
Consider a scenario where, during the creation of a dataflow, you need to retrieve customer details using the Get Customer Details API.

Solution
You can add an API Request Block with the following details.

Method: GET
URL: https://{host}/v2/customers/lookup/customerDetails
Query Parameters:
- Key: embed
- Value: points, mlp

Configuring the API Request Block

To configure the API Request block, perform the following:

From the dataflow canvas, click on the connector.
Select the API Request block from the pop-up window.
In the Block name section, enter the block name.
Note: Block names cannot contain spaces or special characters, except for underscores (_). Use camelCase or snake_case formatting.
In the Method section, select a method from the drop-down menu. The available methods are GET, POST, PUT, DELETE, and PATCH.
In the URL section, enter the API URL.
Syntax: https://{host}/{URL}
Example: https://{host}/v2/customers/lookup/customerDetails
In the Query Parameters section, enter the key and its corresponding value. The entries into the Key and the Value fields depend on the API parameters.
Example: For the API endpoint https://{host}/v2/customers/lookup/customerDetails, some of the query parameters are source, embed, and identifierName. The query parameters are set as Key, and their corresponding values are provided as Value.
Consider the parameter embed. Some possible values for embed are points, subscriptions, and mlp. So, if the Key is embed, the Value can be points, subscriptions, or mlp.
If applicable, in the Path Parameters section, enter the Key and its corresponding Value . The entries into the Key and the Value fields depend on the API parameters.
Example: For the API endpoint, https://{host}/api_gateway/loyalty/v1/programs/{programs}/promotions/{promotions}/get, the path parameters are program and promotion. Here, program and promotion are set as Key, and their respective values should be provided in the Value section.
If applicable, in the Headers section, enter the Key and its corresponding Value. For more information on headers, see Header Management in Neo.
Configure the Input execution logic, Cachable feature and define the execution path as per the requirement.
Click Done.

Header Management in Neo

Headers in an API request are used to send additional metadata, set authentication, define the payload format, specify compression methods for data transfer, and include logging details.

Headers in Neo originate from either a request or a configuration. A request is an input message that includes a payload, headers, URL, parameters, and method. Configuration consists of predefined settings and options managed through files or databases.

Below is a list of headers available in Neo. Additionally, you can create custom headers according to your requirements.

Key	Description	Possible Values & Default Value	Origin of headers	Modifiable in the dataflow
Content-Type	The Content-Type header specifies the format of the request or response body. It tells the server or client how to process the transmitted data.	application/json application/xml Default: application/json	Default: Configuration	Yes
Accept-Encoding	The Accept-Encoding header informs the server about the compression methods supported by the client. This helps reduce the response size and speeds up data transfer.	gzip, deflate, br	Configuration	No
User-Agent	The User-Agent header identifies the API client for the server. It helps the server customize responses based on the client’s software, operating system, or device type.	neo	Configuration	No
Referrer	A header that indicates the source of a request. It helps Neo identify where the request originates.	Execute URL. The Execute URL refers to the URL of the Neo dataflow that is triggered.	Request	No
Authorization	Applicable for API requests that comes directly from POS terminal to the Capillary Server.	The Authorization header value is constructed using the below format: `Basic <Base64 encoded (username:md5(password))>`	Request	Modifiable in a hierarchical organization using the OrgContextSwitch block to switch the dataflow execution context from the parent organization to the child organization.
x-cap-api-oauth-token	A custom authentication header for Capillary internal APIs. Applicable for POS server-to-server integration, FTP server-to-server integration, Server-to-server custom integration and Prebuilt server-to-server integrations	OAuth token generated using the API key and secret.	Request	Modifiable in a hierarchical organization using the OrgContextSwitch block to switch the dataflow execution context from the parent organization to the child organization.
x-cap-api-auth-key	A custom authentication header for Capillary internal APIs. It adds an extra security layer to verify API requests and ensures that only authorized clients can access Capillary’s services.	Secret key set at the organization level	Request	Modifiable in a hierarchical organization using the OrgContextSwitch block to switch the dataflow execution context from the parent organization to the child organization.
x-cap-api-auth-org-id	A custom authentication header for Capillary internal APIs. It identifies the organization making the API request.	Organization ID	Request	Modifiable in a hierarchical organization using the OrgContextSwitch block to switch the dataflow execution context from the parent organization to the child organization.
x-cap-neo-block-log-level	A custom header for Capillary internal APIs that defines the log level for the Neo platform, similar to the logger in the Script block. Logs are generated according to the specified level.	debug, info, warn, error Default: Debug	Configuration	Yes
x-cap-neo-debug-enabled	A custom header for Capillary internal APIs, when set to true, captures platform logs from all services processing the request, not just Neo.	True or false Default: False	Configuration	Yes You can also use the Dev Console to set or change the value of this header.
x-cap-neo-dag-scope	A custom header in Capillary’s Neo platform that defines the scope of execution.	Org, global, parent Default: org	Default: Configuration Overridden when included in the request headers.	Yes
x-cap-neo-test-variant-id	A custom header specifying the variant ID of the dataflow. This is applicable for Capillary internal APIs.	No default value	Request	Yes
x-cap-api-attribution-entity-code	A custom header for Capillary internal APIs used to specify the code associated with a particular entity type.	No default value	Request or Configuration	Yes
x-cap-api-attribution-entity-type	A custom header for Capillary internal APIs that specifies the type of entity posting the data.	TILL, STORE_CODE, STORE_NAME, STORE_EXTERNAL_ID, STORE_EXTERNAL_ID_1, and STORE_EXTERNAL_ID_2 Default: Till	Request or Configuration
x-cap-request-id	A custom header that uniquely identifies each request. The system uses this header for tracking and logging. This is applicable for Capillary internal APIs.	No default value	Request	Yes
x-cap-direct-replay	A custom header that determines whether the system processes the request synchronously or asynchronously. This is applicable for Capillary internal APIs.	No default value	Configuration	Yes