Whenever you request that a transaction be put into the background, there needs to be a mechanism for notifying you that the request has been completed. This notification will push you the high-level details of the result, and you can then query the results at your leisure.
The same notification process will also be used to push alerts to your system. This means that RequestIDs may not match your records
This will be the same RequestId that was sent in the 202 acceptance response.
If you’re calling a processing function of some kind, a check number will be issued. This field will only be present if the function you’re calling would normally return a checkId (such as scan, verify, and compare).
Only supplied if the original request was tied to a document. This will be the same ID that was sent in the original acceptance.
If the entity in entityId above has had an external service ID attached to it in the entity extraData with kvpKey = customer_reference, then this is that kvpValue
Only supplied if the original request was tied to an entity. This will be the same ID that was sent in the original acceptance.
Additional fields that contain the detailed data that was used to generate the ‘message’ field. The actual content will depend on the ‘notificationType’ and ‘function’.
Short description of the original function called, or function that was triggered.
High level indication of the final disposition of a backgrounded function
URI for resource containing more details about the reason for the notification.
A brief, human readable message describing the reason for the notification.
Indicates the type of notification being pushed.
Unique identifier for every request. Can be used for tracking down answers with technical support.
Uses the ULID format (a time-based, sortable UUID)
Note: this will be different for every request.
The portal username that initiated the operation that led to this notification. If applicable and available.