Examples

We've tried to provide examples of some of our most leveraged event types in the pages below. This list is not exhaustive, but provides a solid introduction in how Blend's events are structured across various use cases.

Important Notes

Key Ordering

The ordering of keys within a JSON object is not assured. However, the ordering of elements within a JSON array is preserved. This means that you should not expect keys to appear in any certain order in non-array attributes of Blend's events, but you may depend on their existence where we have explicitly noted them as "required" fields. For more information about key ordering in JSON, please refer to RFC 7159 Section 4.

Field Uniqueness

Keys in the "fields" object are guaranteed to be unique within the "fields" object, but are not guaranteed to be globally unique.

Additive Field Attributes

For each example event, Blend provides some field keys that are considered "required," meaning that they MUST appear in outbound messages of that specific type. However, Blend does not consider additions to the "fields" object breaking, only key name changes or deletions. This means that when constructing validation against inbound events from Blend's event producer, you should not error on unknown fields but only on explicitly defined fields since, from time to time and to enable new functionality in an iterative way for our clients and partners, Blend will add new fields to the outbound "fields" object.

Links

The links object provides a valid URI at the time of event emission. The URI is coupled tightly with the version of the events service and API referred to in the Event Headers as the "blend-api-version" and the links are only valid within the scope of that major version (e.g. routes for 3.x.x will not assuredly work with 2.x.x or 4.x.x versions of the API). The inclusion of the link attribute in the event body is contingent upon the existence of relative routes for that event and is optional.