HTTP triggers

You can use triggers to send HTTP Get and Post requests and send SMS messages.

Processing Responses from HTTP Triggers

After the HTTP response is retrieved by GET, POST, or SMS Trigger, the system stores two values and makes them available for subsequent Triggers through the getSharedValue() API (see rbv_api.getSharedValue()):

Name Value Example
ReturnStatus HTTP Status rbv_api.getSharedValue("ReturnStatus")
ReturnBody HTTP Body rbv_api.getSharedValue("ReturnBody")

For example:

  1. Create an HTTP GET or HTTP POST trigger.
  2. Create an Object Script and configure it to run immediately after HTTP trigger. Use the following API calls in Object Script trigger: 
 var code = rbv_api.getSharedValue("ReturnStatus");
 var body = rbv_api.getSharedValue("ReturnBody");

Now you can analyze HTTP return code and response's body and perform appropriate action.

Tip: You can create powerful integrations by sending HTTP requests and then processing the results in a subsequent Object Script Trigger. Please note that second etc. HTTP call will override shared values set on the first call. Store these values in intermediate variables if you need to preserve them.

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.