OpenSettle

This request HTTP header advertises which content encoding (usually a compression algorithm) the calling application is able to understand. The server selects one of the proposals, use it and informs the client of its choice with the Content-Encoding Response header. Currently supported gzip and deflate. Please note if this request header is not present, no compression will be used.

This general HTTP header controls (or rather influences) whether the network connection stays open after the current request finishes. If the sent value is keep-alive, the connection should stay in a special state, allowing to be reused for subsequent requests to the same server. Please note these connections will be closed after reaching timeout threshold controlled by EES server (usually after 5 seconds).

Standard HTTP header to inform EES API what type of content was passed in request payload

Client ID, provided by EES during on-boarding. Please note: the authentication mechanic requires the receipt of the full payload so any headers that would chunk the request up, such as transfer-encoding: chunked could potentially cause authentication failures.

Request Authentication Hash, calculated by concatenating Request URI Path with API prefix, Request Query String(s) if applicable, Request Payload if applicable and Client Secret. Please note: the authentication mechanic requires the receipt of the full payload so any headers that would chunk the request up, such as transfer-encoding: chunked could potentially cause authentication failures.

Optional Unique Reference for the API Request (Transaction) within the calling company

Optional header provided by the calling application for EES AIR to identify what was the external Subsystem ID / Name. Please note this header is not essential for AIR to process a Request, this header and its value will be intercepted by AIR and will show up in Wallet Event Notifications, if applicable.

Optional header(s) provided by the calling application to EES AIR. Please note a) this header name has to follow pattern X-CUSTOM-* (i.e. X-CUSTOM-EMAIL) b) this header is not essential for AIR to process a Request, this header and its value will be intercepted by AIR and will show up in Wallet Event Notifications, if applicable.

The ability to specify the date and time that should be used to adjudicate. This can be used to create transactions for past events, whilst ensuring the consumer receives the rewards that they were eligible for at that time. This functionality is only available for events less than 6 months in the past. Please note requested transaction date-time has to use ATOM Date-Time format Y-m-d\TH:i:sP, (e.g. 2017-12-31T23:59:59+09:00).