Event Headers

Outbound Events

Blend's outbound HTTP requests contain a number of headers. As a matter of practice, you should always allow additional headers to be passed, but can expect that at minimum the four headers below will be sent with each outbound Event request.

"headers": {
  "content-length": "528",
  "requestdt": "2019-05-23T04:49:13.095Z",
  "requestid": "e00ed870-735f-4a72-958e-e93e6e771319",
  "bonsprofile": "default"
}

content-length

From RFC 7230: "When a message does not have a Transfer-Encoding header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length indicates the size of the selected representation."

requestdt

An ISO 8601 compliant date and time string, always written in UTC as denoted by the trailing Z, which describes the system time when the event was dispatched from the event system. Please note that in this does not represent the time at which the event was generated by the source system, only the time at which the request itself was dispatched, so in the event of retries, this date time stamp will be strictly greater than generation date time stamp included in the event body.

requestid

An RFC 4122 UUID Version 4 string which serves as the unique identifier for the emission of a specific request. This is different than the eventId contained within the request body, for example, as in the event of a retry the eventId will remain consistent but the requestid will be unique for each retry. This header can be used in conjunction with the eventId from the request body and the requestdt header to construct a timeline of retry attempts against a single emitted event.

bonsprofile

A string with a custom-defined value that will be provided to you during your integration with Blend's API and Events system. In most cases, this value will be "default" but may vary based on your specific integration pattern. BONS supports multiple "profiles" so that a single listener can receive different events and tell the difference between those event streams. A common use case for the profile is during API version upgrades of your listener, you can run concurrent profiles on your current version and your new development version side-by-side for testing before completely transitioning to the new version.

Inbound Event Requests

In order to interact with the Event API, certain Blend-specific headers are required in addition to standard HTTP headers you might send with a request.

"headers": {
  "blend-api-version": "2.3.0",
  "blend-target-instance": "bankabc~uat",
  "bons-profile": "default"
}

blend-api-version

A Semver 2.0.0 compliant version number that describes the version of the API that you are leveraging. Note that not all calls are available in all versions, and versions are supported in accordance with Blend's API Release Process.

blend-target-instance

A string of the form "tenantName~instanceName" which describes where your API request should be routed. Note that all requests are authenticated, so your API user must have access to the "blend-target-instance" you pass in your request for the call to succeed. Not all target instances have an "instanceName" part; in fact, in production environments, it is common for this string to simply be the "tenantName" part. This will be provided to you during the implementation phase of your integration by Blend.