Blend's SLA for Event Subscription set-up is 5 business days from time of acknowledgement.
Yes. If you are integrating with Blend across multiple solutions, say for LOS, CRM, and Credit, you might prefer that some events be sent to one listener and some events be sent to a different listener. Alternately, you may wish for different decorators for your varied use cases.
We can create multiple subscriptions for a single customer or partner. The same destination URL can be used across multiple subscriptions with the help of the
bons-profile setting, which allows listeners and callers to distinguish between event streams for receipt and when querying via the Events API.
Event Decorators are Deprecated since Version v3.0.0
We are no longer supporting event decorators for all events in newer event versions (v3.0.0 and above). Additional information provided by decorators can be retrieved using Blend public APIs.
Blend recommends enabling events in your UAT or Beta environments and targeting your test listener; this ensures that the event pipeline of different environments is isolated throughout the testing process. After the subscription is activated, your testing team can take actions in Blend (e.g. submitting a test loan) and ensure that they are being handled by your listener as expected.
Once you are confident that the subscription is working the way you need, you may request that your Deployment Lead or Account Manager promotes your UAT / Beta configuration to the production environment of your choosing.
If I subscribe to an event, can you filter then events you send me based on information in the event?
No. Blend allows subscriptions to select the type of event(s) they are interested in subscribing to, but requires that listeners implement filtering at any level below the event type (e.g. origination type).
If an attempt to send an event to a registered listener fails, Blend will attempt to retry sending the event over the course of 24 hours, backing off retry frequency with future failures.
After 24 hours Blend will marked the event as failed and no longer try to send the event to you. In order to process the event, you will have to retrieve it from the Blend event queue directly via the Events API.
We do not guarantee an exact retry backoff cadance, only that a qualifying event will be retried for approximately 24 hours before finally being transitioned to a terminal failed state. Once transitioned to the terminal failed state, only a manual retry will cause the event to be resent.
- If Blend responds with a 40X error, the partner integration has sent an unauthorized or malformed request. The partner integration should fail and follow any instructions provided in the error message to resolve the issue.
- If Blend responds with a 500 or 503 error, the partner integration may retry errors over a period of time decided on by the partner.
What IDs should we use to link to an object with in Blend's systems? Can we use crmID, losID, or Loan Reference Number?
Blend provides two types of identifiers: named IDs and the polymorphic
[entityType, entityId] duple. In both cases, these object IDs (e.g. loanId, partyId, entityId, etc.) are guaranteed to be unique within the
[environment, tenant, objectType] triple. While it is incredibly rare for a collision to take place within an
[environment, tenant] pair, it is best practice to assume that identifiers are unique only within an object's class. Please note that uniqueness is not guaranteed between environments or between tenants.
Some events can be decorated with additional useful IDs such as crmID, losID, and Loan Reference Number. These IDs can be used to retrieve objects from Blend's APIs but are not appropriate to use as correlation ID in most use cases because they are mutable through Blend's API, Blend's web interface, or both.
I changed the crmID, losID, or Loan Reference Number via the API, but I still received some events where those values are null.
Due to many possible factors (network congestion, system maintenance, and myriad other challenges), Blend does not guarantee that events are received in any particular order by a listener. We do, however, provide consistently produced timestamps that are sent as a top-level attribute in all events. Any events that were queued to be sent prior to your change will not reflect these updates. This includes events that you retrieve through the Events API. Only those events created after the change was made will reflect the update.
Practically, this means that a listener may receive events after making an API change in real clock time, that do not reflect that change because they event time reflected in the event timestamp was queued and processed for delivery prior to your API call.
Updated 18 days ago