HomeGuidesAPI ReferenceChangelogDiscussions
GuidesAPI ReferenceDiscussions

# How long will it take once I file my request for a subscription for the subscription to be active?

Blend's SLA for Event Subscription set-up is 5 business days from time of acknowledgement.

# Can I create multiple subscriptions?

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.

# How can I exercise my listener and test my events subscription?

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 our endpoint responds with an error what will Blend do?

If an attempt to send an event to a registered listener fails, Blend will attempt to retry sending the event over the course of 48 hours, backing off retry frequency with future failures.

After 48 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.

# If we call Blend and Blend responds with an error, what behavior does Blend expect?

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

# What other identifiers can Blend provide?

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.