In order to send requests through the bLink APIs, different custom headers need to be sent. The following table shows the currently defined custom headers for bLink, however the specific custom headers for each use case are defined in the endpoints documentation.
|The unique identifier that identifies the Service Provider.
|The unique identifier of the client forwarded to the provider (SCOPE: FI).
|The unique identifier (defined by the caller) which will be reflected back in the response.
|Name and version of the Service User's software.
|ACME Moneymaker v2.0
|User agent of the Service User initiating the operation. This header can be used by the Service Provider for fraud detection features.
|Mozilla/5.0 (Windows NT?) or AUTO
|IP address of the user Service User initiating the operation. This header can be used by the Service Provider for fraud detection features.
|188.8.131.52 or AUTO*
|Indicates if the response was created by the Corporate API platform or by the Service Provider (SCOPE: SIX)
|PLATFORM or PROVIDER
|Identifies the domain name for which a request is being sent to the server. This header must either be empty or not overwrite the actual host domain name.
Correct Correlation-ID usage
The Correlation-ID shall be used to uniquely identify a single REST call (request/response) on its way through all the systems involved, be it at the Service User, bLink or the Service Provider. Due to its unique character, the Correlation-ID may be used for debugging purposes as well as for log analytics, e.g., measuring latency of components, round-trip time, etc.. Using the same Correlation-ID value for multiple REST calls will render such analytics useless.
The Correlation-ID shall not be used for grouping multiple calls belonging to the same business (trans)action, e.g., fetching transaction lists for multiple accounts from the same SP (one REST call per account, all using the same Correlation-ID). If a Service User needs to correlate on a business (trans)action, e.g., all transactions of a batch we recommend to use a two-part Correlation-ID composed of a fixed “batch” prefix and a unique postfix per transaction, e.g., “Batch-ID//unique ID”. The uniqueness of the Correlation-ID is thereby guaranteed, and the Service User can still correlate with the “batch” prefix.