HTTP Headers

Content

• Overview
• Standard REST Headers
• ULM Cloud-Specific Headers
• Cookie Headers
• Revision History

Overview

The following sections state and describe a variety of standard and ULM-specific headers that ULM APIs both consume and produce.

Standard REST Headers

Content-Type

Specifies both the media type (of the content of the request body) that the client sends to the ULM Cloud, as well as the media type (of the content of the response body) that ULM returns to the client. Requests sent to ULM Cloud must be in a proper JSON format, and thus the header must use application/json.

Content-Type: application/json

This header is mandatory. The request returns an error if no Content-Type is supplied.

Accept

Specifies the media type(s) that the client is capable of accepting in the body of a response. Clients must support accepting the application/json media type, as it is the only format in which ULM exchanges data.

Accept: application/json

While this header is not strictly mandatory for clients to provide (ULM will assume application/json without it), clients are encouraged to include it.

Note: The list of all standard REST headers is available here.

ULM Cloud-Specific Headers

X-Partner-AUTHZ

Facilitates machine-to-machine (M2M) partner authorization. A partner is any machine or protocol that can retrieve resources from the ULM Cloud through specific partner-class APIs. Machines that access protected APIs must include the X-Partner-AUTHZ authentication key in the HTTP header of in every request.

The authorization header is a base64 encoding of a partner key and partner secret, provided by ULM Cloud when the partner is created. For example: a partner with a key of ec31969c-2b3c-4b94-951e-79364efe4c78 and a secret of AI1BqhPMKwTa8q9tR/n5f3WUpp8hX2HIGeSitsEsK3A6 looks like this in the header:

POST http://~your.url/rest/{version}/activation/user

X-Partner-AUTHZ: dgTXlHWaYKwuQTnvnfI/TPjZpr+YXPifcG44aJ9WAeI

X-B3-TraceId

Returned by ULM Cloud on every request. The header value contains of a uniquely generated string to identify the request for logging and/or tracing purposes.

X-B3-TraceId: dd950f07f143ebcb

Clients may optionally provide this header with their own requests, set to a value of their own choosing (or generation). ULM will use this client-supplied value instead of generating one. This may be desirable in machine-to-machine integrations with ULM Cloud, wherein tracing requests (and subsequent responses) across multiple different services requires consistent trace IDs across all components.

Note: See Request Tracing for more details.

X-Tenant-ID

Returned by ULM on every request. This header identifies the ULM Cloud tenant this API is serving. Clients typically do not need to concern themselves with this header.

X-Tenant-ID: maple

X-Correlation-Process-ID

Returned by ULM on every request involving a ULM Process (see ULM Processes: Overview for more information). This header provides the unique identifier for the current instance of the Process. The value matches the processId returned returned in the response body.

X-Correlation-Process-ID: c4ca8b77-898b-4ee0-a74a-e4f5947b9162

X-Total-Count

This header identifies the total count of available results for a request, when the response returns multiple results.

The header is used to support Pagination parameters.

GET /runtime/{runtimeId}/features
 
Header: X-Total-Count = 12

Cookie Headers

The following headers are sent along in a REST response to be stored by the client.

JSESSIONID

Assigned when a user (or ULM Admin user) authenticates into ULM, and the system opens a user session on the server. Used by all non-anonymous endpoints.

JRUNTIMEID

Runtime cookie for tracking the runtime device from which a user is accessing a service (by signing into ULM).

mint-sso-token (Remember Me cookie)

Assigned to a user when they log into ULM. Acts like a remember me cookie for auto-login.

Revision History