HTTP headers supported by Cortex
Request Headers
Authentication
Cortex supports the following standard HTTP request headers for authenticating a user:
Authorization
Sets the access token, which was created by the reference OAuth2 implementation.
Accept
Specifies the Cortex response format used. The options are:
application/json: The responses are returned in the plain JSON formatapplication/hal+json: The responses are returned in the HAL (Hypertext Application Language) format
Accept-Language
Sets the client’s language and preferred locale variant.
Custom Headers
Cortex supports setting these custom HTTP request headers:
X-Ep-Data-Policy-Segments
Specifies the data policy segments relevant to the current customer. You can specify more than one data policy segment by separating the segments using a comma. You can view the data policies associated with a data segment by entering the data policy segment name in the X-Ep-Data-Policy-Segments header.
X-Ep-User-Id
Sets the identifier of the shopper. This can be used when integrating with an alternate authentication provider in a trusted environment.
X-Ep-User-Roles
Sets the roles of the shopper. This can be used when integrating with an alternate authentication provider in a trusted environment. Multiple roles should be separated by commas.
X-Ep-User-Scopes
Sets the scopes that the shopper can access. This can be used when integrating with an alternate authentication provider in a trusted environment. Multiple scopes should be separated by commas.
X-Ep-User-Traits
Sets the shopper’s traits (including language and currency) which are used to personalize the responses returned to client.
X-Ep-Account-Shared-Id
Optionally specifies the shared ID of the account that a shopper is buying on-behalf-of. If not specified, Cortex implies that the shopper is buying for themselves. The value can only be set to the shared ID of an account that the shopper is associated to, otherwise an error will be returned.
X-Forwarded-Base
Sets the alternate base URL for the links returned in a response. This rewrites the links base URL, which is useful when Cortex is deployed behind a proxy server.
X-Correlation-Id
Allows the client to set a unique identifier that will be included in the output for all log events related to the API request, including Integration Server operations triggered by JMS event messages. This allows an operations team to review all logs across multiple services for a specific request through a log aggregation tool.
Response Headers
Cortex returns these standard HTTP response headers:
Cache-Control
Contains the response’s cacheability.
When a resource’s max-age is not set, Cortex sets the following cache control header:no-cache.
When a resource’s max-age is greater than 0, the cache-control max-age property is set to match. For instance, if a resource’s max-age is set to 600, then Cortex sets the following cache control header: private, no-transform, max-age=600
Content-Type
Contains the response’s media-type.
Location
Contains the reference location of a newly created resource.
Content-Security-Policy
Always set to default-src 'none' to prevent inline Javascript from being executed, as recommended by the Open Web Application Security Project.
Referrer-Policy
Always set to no-referrer to prevent referer details from being shared with Cortex, as recommended by the Open Web Application Security Project.
Strict-Transport-Security
Always set to max-age=31536000 ; includeSubDomains to ensure that Cortex is always expected to be served on HTTPS connections, as recommended by the Open Web Application Security Project.
X-Content-Type-Options
Always set to nosniff to prevent the browser from interpreting files as a different MIME type to what is specified in the Content-Type HTTP header, as recommended by the Open Web Application Security Project.
X-XSS-Protection
Always set to 0 in order to disable the Cross Site Scripting Auditor, and not allow it to take the default behavior of the browser handling the response, as recommended by the Open Web Application Security Project.