User Documentation

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.

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:

  1. From the dataflow canvas, click on the connector.
  2. Select the API Request block from the pop-up window.
  3. 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.
  4. In the Method section, select a method from the drop-down menu. The available methods are GET, POST, PUT, DELETE, and PATCH.
  5. In the URL section, enter the API URL.
    Syntax: https://{host}/{URL}
    Example: https://{host}/v2/customers/lookup/customerDetails
  6. 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.
  7. 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.
  8. If applicable, in the Headers section, enter the Key and its corresponding Value. For more information on headers, see Header Management in Neo.
  9. Configure the input execution logic, cachable feature, and define the execution path as per the requirement.
  10. Click Done.
Configuring API Request block

Configuring API Request block

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.

KeyDescriptionPossible Values & Default ValueModifiable in the dataflow
Content-TypeThe 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/jsonYes
Accept-EncodingThe 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, brNo
User-AgentThe 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: neoNo
ReferrerA 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
AuthorizationApplicable 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-tokenA 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-keyA 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-idA 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-levelA 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-enabledA 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-scopeA custom header in Capillary’s Neo platform that defines the scope of execution.Org, global, parent
Default: org		Yes
x-cap-api-attribution-entity-codeA 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-typeA 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-idA 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-replayA 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

Updated about 2 months ago