## Defined Types
Standard HTTP error codes
|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|
CONSUMER_MORTGAGE CONSUMER_BANKING AUTO INSURANCE WHOLESALE_MORTGAGE
created updated deleted
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.
## 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.