HTTP request headers

HTTP request headers are utilized by the flowcontext_in and flowcontext_out cards of ITX maps, and are also used for routing and authentication.

HTTP headers

The following list provides an explanation of HTTP header information.

Note: Values can be specified in either the URL or in HTTP headers and are not case-sensitive. Unless otherwise specified, all values are optional. If a value is provided as both an HTTP header and a URL parameter, they must match, or an error will be returned to the customer.

Authorization: Rrequired if not provided in a URL parameter. Contains a base-64 encoded string of the agreed-upon username:password values for HTTP basic authentication
Note: The Authorization header cannot be provided if the username URL parameter is provided, or an error will occur.
X-Sender-Id: Required if not provided in a URL parameter. A value that identifies the sender; can be a static value per client.
X-Receiver-Id: Required if not provided in a URL parameter. The shipper ID or carrier code
X-Document-Type: Required if not provided in a URL parameter. A value that identifies the type of data that is sent in the payload.
X-Request-Type: IBM implementers can use this value to determine which flow to call.
X-Mode: Tells whether the flow is synchronous or asynchronous. Valid values are sync, async and check. A value of check indicates that the Rapid Transit POD will use a specified value for lookup, which can be configured in legacy InFlight under Rapid Transit Decision Criteria. If this property is left blank, the flow defaults to synchronous.
X-Mode-Check-Field-1: Indicates which header or parameter to use for the mode lookup as Text 1.
X-Mode-Check-Field-2: Indicates which header or parameter to use for the mode lookup as Text 2.
X-Mode-Check-Field-3: Indicates which header or parameter to use for the mode lookup as Text 3.
X-Mode-Check-Field-4: Indicates which header or parameter to use for the mode lookup as Text 4.
X-Mode-Check-Field-5: Indicates which header or parameter to use for the mode lookup as Text 5.
X-Mode-Check-Field-6: Indicates which header or parameter to use for the mode lookup as Text 6.
X-Mode-Check-Field-7: Indicates which header or parameter to use for the mode lookup as Text 7.
X-Mode-Check-Field-8: Indicates which header or parameter to use for the mode lookup as Text 8.
X-Mode-Check-Field-9: Indicates which header or parameter to use for the mode lookup as Text 9.
Note: Each X-Mode-Check field corresponds to the Text field of the same number on the Rapid Transit Decision Criteria screens. For example, X-Mode-Check-Field-1 corresponds to Text 1. If a check field is not specified (for example, if X-Mode-Check-Field-2 is left blank), the Rapid Transit POD looks for criteria where the text field of the same number (for example, Text 2) is empty.

HTTP response information

The following lists indicate what to expect from failed and successful HTTP responses of various types.

Synchronous flow

Success: – A 200, or OK, response, with the body containing the data from the shipper and appropriate label information, if required
Failure: A 400- or 500-level error

Asynchronous flow

Success: 202, or Accepted, response, with a static body
Failure: A 400- or 500-level error with a meaningful explanation in the body, if available

Encoding

Encoding is determined from either the endpoint character encoding or the carrier response encoding.