API Jitterbit variables in Integration Studio¶
Introduction¶
This page covers Jitterbit variables that are available for Jitterbit custom APIs, organized by informational variables that you read (Informational), and settings variables that you write (Settings).
Variables ending in an asterisk (*) are to signify that the asterisk is to be replaced with a header name, such as in jitterbit.target.http.response.header.X-Jitterbit-Authorization
.
Note
For Jitterbit variables with a hyphen in their name, use the Get
and Set
functions to retrieve and set their values. For example: Get('jitterbit.target.http.response.header.X-Jitterbit-Authorization')
.
For detailed information on using Jitterbit custom APIs, see API Manager.
Informational¶
jitterbit.api.request.body
and jitterbit.api.request.body.*
¶
Data type¶
String
Description¶
Looks at the payload/payloads submitted to the API. Note that for the majority of the APIs, you would expect only one plain payload and, as such, jitterbit.api.request.body
is the variable to use (also known as content-type:text/plain
).
If you expect multiple payloads to be submitted at once, using the URL-encoded form (also known as content-type:application/x-www-form-urlencoded
), as in the case of an API being used as the backend of a submission form (see http://www.w3.org/TR/html401/interact/forms.html), then you should be using jitterbit.api.request.body.*
. As with jitterbit.api.request.parameters.*
, jitterbit.api.request.body.name
will be equal to EStore
if the value of the form's field "name" was entered as EStore
.
jitterbit.api.request.enum.body
¶
Data type¶
String
Description¶
Variable array used to dynamically iterate through all of the submitted parts of the payload/body (instead of checking a specific part as with jitterbit.api.request.body.*
). The usage is the same as with the jitterbit.api.request.enum.parameters
.
jitterbit.api.request.enum.headers
¶
Data type¶
String
Description¶
Variable array used to dynamically iterate through all of the request headers (instead of checking a specific header as with jitterbit.api.request.headers.*
). The usage is the same as with the jitterbit.api.request.enum.parameters
and jitterbit.api.request.enum.body
.
jitterbit.api.request.enum.mvparameters
¶
Data type¶
String
Description¶
Variable array used to dynamically iterate through all of the multi-value parameters (as opposed to checking each parameter specifically as jitterbit.api.request.mvparameters.ProdID
).
jitterbit.api.request.enum.parameters
¶
Data type¶
String
Description¶
Variable array used to dynamically iterate through all of the submitted parameters (as opposed to checking each parameter specifically as jitterbit.api.request.parameters.name
).
This sample script appends all of the provided parameters to a new variable for later display back to the user:
<trans>
$output = "URL Parameters: <br>\r\n";
enum = $jitterbit.api.request.enum.parameters;
i = 0;
while(i<length(enum),
name = enum[i];
$output = $output + "$" + name + ": " + Get(name) + " <br>\r\n";
i = i+1;
);
if(i==0, $output = $output + "(none)<br>\r\n");
</trans>
jitterbit.api.request.headers.*
¶
Data type¶
String
Description¶
Variable used to look at the request headers submitted to the API; for example, $jitterbit.api.request.headers.x_forwarded_for
is the public IP of the box/user accessing the URL.
jitterbit.api.request.headers.fulluri
¶
Data type¶
String
Description¶
The URL that was called to trigger the Jitterbit OData or custom API.
jitterbit.api.request.method
¶
Data type¶
String
Description¶
The request method that was used to call the API.
jitterbit.api.request.mvparameters.*
¶
Data type¶
String
Description¶
Looks at the multi-values of the parameter submitted to the API directly through the URL and returns the values as an array with a space between each value.
For example, if the URL is https://jitterbitxx.na.jitterbit.org/dev/ProductAPIResponse?ProdID=abc&ProdID=abc1&ProdID=abc2
, then jitterbit.api.request.mvparameters.ProdID
will be abc abc1 abc2
.
jitterbit.api.request.parameters.*
¶
Data type¶
String
Description¶
Looks at the parameters submitted to the API directly through the URL; for example, jitterbit.api.request.parameters.name
will be equal to EStore
if the URL requested had &name=EStore
.
Note
Multi-value URL parameters will return a string delimited by |||
(3 pipes). To return multi-value URL parameters as an array, use the jitterbit.api.request.mvparameters.*
variable instead.
For example, if the URL is https://jitterbitxx.na.jitterbit.org/dev/ProductAPIResponse?ProdID=abc&ProdID=abc1&ProdID=abc2
, then jitterbit.api.request.parameters.ProdID
will be abc|||abc1|||abc2
.
Settings¶
jitterbit.api.response
¶
Data type¶
String
Description¶
This variable must be set if your custom API is configured to use a System Variable as the response type. The jitterbit.api.response
variable can be used multiple times throughout an operation chain, but it must be set for each use.
Tip
The jitterbit.api.response
variable can be set and used in a Variable endpoint to be referenced in the same or downstream operations.
jitterbit.api.response.blank_error_response
¶
Data type¶
Boolean
Description¶
Allows a blank API response to be returned for non-200
-type status codes when jitterbit.api.response.blank_error_response
is set to true
. When set to false
(default), an HTML status page is rendered for the returned status code. Available for use with agent and API gateway versions 10.59 or later.
jitterbit.api.response.headers.*
¶
Data type¶
String
Description¶
Used to set the response headers of the API. For example, set jitterbit.api.response.headers.access_control_allow_origin="*"
to override default CORS behavior and allow the API to be accessed by any domain in a cross-site manner.
jitterbit.api.response.status_code
¶
Data type¶
String
Description¶
Provides the ability to override HTTP response code for custom APIs using a Jitterbit script variable. Set the jitterbit.api.response.status_code
variable in the script that is executed by a custom API. This allows project authors to set a specific HTTP error code (along with actual payload information) versus relying on the system to return codes 200 or 500 based on default behavior.