HomeGuidesAPI ReferenceChangelogDiscussions
GuidesAPI ReferenceDiscussions


## 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 headers below will be sent with each outbound Event request.



## 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."

## blend-request-datetime

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.**

## blend-request-id

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.

## blend-events-profile

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. The Events system 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.

## blend-target-instance

A string that denotes from which Blend instance the event originated. This is useful for partner integrations that may receive data from multiple instances or for customers with DBA's that need to add routing logic for received events by DBA instance.

## 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](🔗).

## 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.



## 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.

## blend-events-profile

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. Blend Events 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.