rbv_api.sendHttpRequest

Purpose

Platform server-side API to provide end-users the ability to invoke RESTful web services. This API will be available for triggers and formula.

Note: Administrators must be careful while constructing the url of the target REST service, as they should not use tokens, for which the value can be changed by end users. By modifying tokens values, malicious users could invoke a different REST service and potentially leak data they do not have access to.

Syntax

rbv_api.sendHttpRequest(url, method, headers, params, body, options);

Parameters

url

The REST Service URL. This function argument is mandatory.

method

The HTTP method. This function argument is mandatory. The POST, GET, PUT, and DELETE HTTP Methods are supported.

headers

The JSON object with key-value pairs to be forwarded as HTTP Request headers.

params

The JSON object with key-value pairs, wherein, each entry denotes HTTP Request parameter name and parameter value.

body

The request payload as a serialized string literal.

options

The JSON object with additional optional arguments as properties.

Property Name	Description
userName	On Platform server side, while establishing HTTP connection to RESTful Service host, Platform supports HTTP Basic Authentication. You must pass the user-name details as this property value.
password	On Platform server side, while establishing HTTP connection to RESTful Service host, Platform supports HTTP Basic Authentication. You must pass password as this property value.
httpReadTimeout	This property configures socket read timeout for the HTTP connection in milliseconds. The default value is 2 minutes. However, this can be configured to a maximum of 8 minutes.
debug	This property logs debug messages (tenant specific) on Platform server-side, while relaying service request and response.
numRetries	This property sets the number of retries allowed for a trigger. The maximum number of retries must not exceed 3.
retryInterval	This property sets the interval (ms) between two subsequent retries. The maximum retry timeout value (Retry Interval * Number of retries) can be configured using `MaxHttpRetryTimeoutInMins` shared.property. Default value of `MaxHttpRetryTimeoutInMins` is 1 min.
statusCodes	This property mentions the HTTP Response codes on which retry should happen. It can be a comma separated values of status codes as well as a range of status codes. For example, 302-400,500.

Note: This new API is a more generic version that can be leveraged for multiple use-case scenarios unlike the existing rbv_api.sendJSONRequest, rbv_api.sendHttpGet, rbv_api.sendHttpPost server-side APIs that are either tied to a particular payload content-type like JSON or specific to a HTTP Request method.

Limitations

HTTP Request with content-type multipart/form-data are not supported. This API primarily works with HTTP Request and Response payload content-types like text/plain, application/xml, application/json, and so on.

Example

var resp = rbv_api.sendHttpRequest('https://jsonplaceholder.typicode.com/
posts/1', 
 GET',
 null,
 null,
 null,
 {userName:'{!#CURR_USER.lastName#value}', password: "{!#SETTINGS.API_Password}", 
  httpReadTimeout: 15000, debug: true, numRetries : "3",
  retryInterval : "2000",statusCodes : "200-300,400,500"});

rbv_api.println('Status:'+resp.status);
 if(resp.status === 200){
 var userObj = JSON.parse(resp.body);
 return 'User ID:'+userObj.userId;
 }
 else {
 rbv_api.println('Error Details:'+resp.status+' '+resp.message);
 }

Support for Base64 Encoding of Binary HTTP Responses

Binary Response Handling (Base64 Encoding)

Previously, all HTTP APIs within the platform returned strings. When remote endpoints sent binary content, converting bytes to text corrupted the data, complicating file downloads and input to binary field APIs requiring Base64.

The Infinite Blue Platform HTTP APIs now support binary and other non-text response types via an optional request header. This enhancement prevents data corruption when processing files such as PDFs, Excel, Word documents, or images.

All HTTP APIs now accept this optional request header:

Header	Value
Content Transfer Encoding	base64 (case-insensitive)

When this header is included in the request:

The API reads the response body as raw bytes.
The API returns a Base64-encoded string of those bytes instead of decoding the content as text.
The returned Base64 value is compatible with existing binaryField API methods.

When the header is not included, all APIs behave as they do currently, returning responses as plain text strings.

Header availability	Response format
Yes (Content Transfer Encoding: base64)	Base64-encoded string of raw response bytes
No	Standard string response (existing behavior)

Example (Server-Side JavaScript)

Downloading a PDF and saving it to a binary field:

var url = "{!DownloadURL}";

var method = "GET";

var headers = {

"Content-Type": "application/pdf",

"Content-Transfer-Encoding": "base64"

};

var params = null;

var body = null;

var options = null;

var resp = rbv_api.sendHttpRequest(url, method, headers, params, body, options);

// With Content-Transfer-Encoding=base64,

// resp.body contains a Base64-encoded string of the PDF bytes.

if (resp && resp.body) {

var fileName = Date.now() + "." + "{!File_Extension}";

rbv_api.setBinaryFieldValue(

"pdftestobj",

{!id},

"fu1",

resp.body,               // Base64 content returned from HTTP API

"application/pdf",

fileName

);

Header value matching is performed in a case-insensitive manner.

Only the response body is subject to modification. Status codes, headers, and associated metadata remain unchanged.

Scripts and integrations that do not transmit the Content-Transfer-Encoding: base64 header maintain compatibility.