API Request Block

Suggest Edits

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.

You can use the API Request Block to invoke the APIs created using DBaaS service gRPC-based APIs. When you use this block, ensure that you use the endpoints https://{host_name}/das/getUserDetails.

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

Request headers are key-value pairs in an HTTP request that provide essential information about the request context. They help the server understand how to process the request and respond appropriately.

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	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.	Default: application/json	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.	Default: gzip, deflate, br	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.	Default: neo	No
Referrer	A header that indicates the source of a request. It helps Neo identify where the request originates.	URL of the Neo dataflow that is triggered.	No
Authorization	Applicable for API requests that come directly from POS terminal to the Capillary Server. The Authorization header value is constructed using the below format: `Basic <Base64 encoded (username:md5(password))>`	If the incoming request to the dataflow includes a value, Neo sets the header with that value. If no value is provided, the header is excluded.	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.	If the incoming request to the dataflow includes a value, Neo sets the header with that value. If no value is provided, the header is excluded.	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.	If the incoming request to the dataflow includes a value, Neo sets the header with that value. If no value is provided, the header is excluded.	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.	If the incoming request to the dataflow includes a value, Neo sets the header with that value. If no value is provided, the header is excluded.	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	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	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	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.	If the value is in the incoming request, Neo uses it. If not, Neo ignores it. However, setting a value in the block properties overrides the request value.	Yes
x-cap-api-attribution-entity-type	A custom header for Capillary internal APIs that specifies the type of entity posting the data.	If the value is in the incoming request, Neo uses it. If not, Neo ignores it. However, setting a value in the block properties overrides the request value.	Yes
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.	If the value is in the incoming request, Neo uses it. If not, Neo ignores it. However, setting a value in the block properties overrides the request value.	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.	If the value is in the incoming request, Neo uses it. If not, Neo ignores it. However, setting a value in the block properties overrides the request value.	Yes
x-cap-neo-sla	A custom header to route non-critical or long-running requests to a separate instance optimised for lower-priority processing, ensuring they do not interfere with high-priority, real-time traffic.	no-sla	Yes

Handling Bulk API Call Errors

When Neo executes multiple APIs in a single request, it handles the error as follows:

If any individual call fails, the respective API Request Block's response displays "msg": "failed" .
Neo continues executing the remaining calls and collects all responses, including the successful ones.

Below is a sample response when Neo executes multiple APIs in a single request.

{
  "api1Output": "1234fjefenjkrfknj4rvjkn",
  "api2Output": {
    "code": 500,
    "message": "{\"code\":500,\"message\":\"UNKNOWN EXCEPTION\",\"err\":\"TypeError: Cannot set properties of undefined (setting 'x-cap-neo-error-msg')\"}",
    "err": {
      "message": "{\"code\":500,\"message\":\"UNKNOWN EXCEPTION\",\"err\":\"TypeError: Cannot set properties of undefined (setting 'x-cap-neo-error-msg')\"}"
    }
  },
  "api3Output": "1234fjefenjkrfknj4rvjkn",
  "msg": "failed"
}

Explanation

api1Output, api2Output, and api3Output are the names of the individual API calls.
api1Output and api3Output contains successful responses.
api2Output contains a 500 error response with detailed metadata.

The msg field shows the overall status. It reads "failed" because api2Output failed.

Using Private APIs

You can use the API Request Block to use the private APIs. These are the gRPC-based APIs created using the DBaaS service, and can be used only using Neo. These APIs will have das in the endpoint.

List of Private APIs Available

Updated about 18 hours ago