Events Schemas & Definitions

Defined Types

error.errorCode:

Standard HTTP error codes

status

Value	Definition	Auto Retry?	Manual Retry?
EMITTED	The state of an event after it is first sent by the BONS HTTP/S agent but before the listener has responded with a status.	NO	YES
ACKNOWLEDGED	The state of an event when a listener responds with a 200 to the emission of an event for an asynchronous subscription.	NO	NO
PROCESSING	The state of an event when updated by an asynchronous response from a listener. This state can be used when an event triggers complex or long-running business processes that may succeed or fail at a later time.	NO	NO
SUCCEEDED	The state of an event when updated by an asynchronous response from a listener to indicate that downstream processing has completed successfully and that there is no need for a retry from Blend.	NO	YES
FAILED	This state is set when a listener responds with any code outside of the 2xx range synchronously or asynchronously through an event state update.	YES	YES
NO_ACTION	This state may be used if, for example, you wish to subscribe to a large set of events but only have the development bandwidth to process a smaller subset of them. You may provide a 204 response on the original call or asynchronously respond with a "NO_ACTION" state update event to halt further retries. This is an ideal solution for enabling faster iterative development.	NO	YES
QUEUED	This state is used to denote the time between when an event is generated by one of Blend's microservices and when it is prepared and ready to be dispatched to a subscriber. During this time, no retries or alterations may be made to the event record and no updates may be posted.	NO	NO
INVALID	This state is used to denote an invalid transmission and may be used with an asynchronous state event only. This state is not retryable and is generally not suggested for use outside of development environments.	NO	NO
CANCELLED	This state is set by an asynchronous state event and is used to describe an event which, at some point during downstream asynchronous processing, has become unneeded. For example, if your systems are processing several disclosures-related events simultaneously and then your receive a notification that the party has declined the disclosure package, you may wish to invalidate all outstanding events to avoid retries.	NO	YES
DISABLED	This state is set by an asynchronous state event and is used to denote that a subscriber has disable processing on a specific event class. This is a good way to gracefully deprecate the processing of certain events within your listeners without having to work with your Account Manager or Deployment Engineer.	NO	YES

solution

CONSUMER_MORTGAGE
CONSUMER_BANKING
AUTO
INSURANCE
WHOLESALE_MORTGAGE

action

created
updated
deleted

type

application
disclosure
document
followUp
party

Event Decoration

At times, adding metadata to events can aid in downstream processing and make integration more efficient. To this end, we offer a set of decorator configurations that may be made available. Decorators are not available on all events; check the event descriptions below for information on which decorators are available for each event type.

Decorators are always injected as independent attributes into the 'fields' object.

Decorators

losPrimaryKey
crmPrimaryKey
originationType
referenceLoanNumber

LOS Primary Key

The name of the loan identifier that links a Blend loan with a record in an LOS. This will only be set if the Blend instance has a LOS integration, or if one is set using the API.

CRM Primary Key

The name of the loan identifier that links a Blend loan with a record in a CRM. This applies to Blend instance's enabled with a CRM integration.

Origination Type

The type of loan (e.g. HELOC) referenced in the event.

Reference Loan Number

The reference number that is displayed in the lender pipeline view of the Blend web interface. Note that with certain role permissions, this number is mutable by users via the web interface.