AlphaTrust e-Sign

Appearance

On this page

Participant Event Subscriptions ​

There are two methods that are supported for notifying your application of these status change events: (1) HTTP POST, and (2) HTTP GET.

TIP

If using HTTP POST, data elements are sent via a standard HTTP(S) POST of urlencoded name value pairs as an “application/x-www-form-urlencoded” mime type. This is the same format used by standard HTTP form post actions, so most server side processors understand how to parse form posts.

TIP

If you only want to be notified only on the first time the participant event occurs, set AlwaysRequired=false (this is the default). If you want to be notified for every time the participant event occurs, set AlwaysRequired=true.

Controlling Your Events ​

You may control the processing of these actions by including optional semicolon-separated name/value pairs in the Data property. Valid values are:

Data ParametersDescription
request-timeoutA value from 30 to 180. This is the number of seconds the AlphaTrust® e-Sign HTTP POST or GET should wait for a response from your listener URL before timing out. The default value is 30 seconds.

Example: Data="request-timeout=60;"
required-response-textA value that AlphaTrust® e-Sign will expect to receive from your listener to indicate that you have processed the POST or GET successfully. If a value is set here, you must use a mime type of "text/plain" in your response to the AlphaTrust® e-Sign GET or POST. Use the HTTP Content-Type header (i.e. "Content-Type: text/plain"). If you do not set this value then AlphaTrust® e-Sign will only look for an HTTP status code between 200 and 299 inclusive to indicate success. If you do set this value then both a success status code and "required-response-text" value match is required. This value is case-insensitive.

Example: Data="request-response-text=RECEIVED;"
retry-limitA value representing the maximum number of minutes to retry status update messages in the case of failed (unsuccessful) GET or POST requests to your listener. Valid values are between 30 and 10080 (7 days), inclusive. If you do not specify this value then a default value globally configured for the AlphaTrust® e-Sign installation is used. The value, by default, is "4320" (3 days). The interval between retries is 5 minutes, unless a different globally configured value is set for AlphaTrust® e-Sign (on-prem/in-stack option only).

Example: Data="retry-limit=1440;"

Common Data Elements ​

Below are common data elements that will be included in all Participants Event Subscriptions.

NameValue
SecurityTokenPlease reference Security Token usage details.
TransIDThe TransID is a standard 10 digit ID used for a transaction as discussed elsewhere. Example: 1234567890
PartIDThe PartID is a standard 10 digit ID used for a participant as discussed elsewhere. Example: 1234567890
PartStatusThe PartStatus will be one of the following one-digit integer values:
  • 2 Pending
  • 4 Complete
  • 6 Email sent - Participant has been notified by email but is still in the Pending status. You will receive a notification every time an email notice is sent to the participant. So if there are three email notices sent, then you will receive three status update messages related to it. This value is only valid for PartStatus and SigStatus.
  • 7 Closed
  • 8 Cancelled
  • 9 Expired
TXStatusThe TXStatus will be one of the following one-digit integer values:
  • 2 Pending
  • 4 Complete
  • 7 Closed
  • 8 Cancelled
  • 9 Expired
  • 10 Voided
PartAccessTokenDEPRECATED
ps_securitytokenguid

Status Change ​

You can subscribe to Participant status change events by adding a Workflow Action to the Participant.

The data elements sent in the GET or POST are all the common data elements plus the following:

NameValue
EventTypeparticipant

WARNING

If the Participant's CancelledTaskBehaviorType is set to AutomaticCancel or DisplayCancelOrSuspendOption and they cancel a transaction, the notification will be sent and the returned TXStatus and PartStatus values for the transaction will be 8. If the Participant's CancelledTaskBehavior is set to AutomaticSuspend, no notification will be sent because the status stays as a 2 which is the pending status. Likewise, if the Participant's CancelledTaskBehavior is set to DisplayCancelOrSuspend and they choose to only suspend their process after hitting the initial cancel button, no notification will be sent because the status stays in a 2 pending status.

csharp
participant = new ParticipantInsertModel()
              {
                  FullName = "John Smith",
                  EmailAddress = "testing@alphatrust.com",
                  SendRequestViaEmail = true,
                  WorkflowActions = new List<object>
                                    {
                                        new ParticipantWorkflowActionModel()
                                        {
                                            Type = ParticipantWorkflowActionModel.TypeEnum.SubscribeToStatusChangeNotificationsByPost, //or ...ByGet
                                            Data = "required-response-text=RECEIVED;retry-limit=1440",
                                            Url = "https://myapp.mydomain.com/statuslistener.php"
                                        }
                                    }
              }

A completed participant from that uses the above code would see something like the following as the posted status notification values:

TransID=1234567890&PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Likewise, if the participant was using a SubscribeToStatusChangeNotificationsByGet method type, the posted status notification value might look something like this:

https://myapp.mydomain.com/statuslistener.aspx?TransID=1234567890PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Session Start ​

You can subscribe to Participant session start change events by adding a Workflow Action to the Participant.

The data elements sent in the GET or POST are all the common data elements plus the following:

NameValue
EventTypeparticipant-session-begin
csharp
participant = new ParticipantInsertModel()
              {
                  FullName = "John Smith",
                  EmailAddress = "testing@alphatrust.com",
                  SendRequestViaEmail = true,
                  WorkflowActions = new List<object>
                                    {
                                        new ParticipantWorkflowActionModel()
                                        {
                                            Type = ParticipantWorkflowActionModel.TypeEnum.SubscribeToSessionStartNotificationsByPost, //or ...ByGet
                                            Data = "required-response-text=RECEIVED;retry-limit=1440",
                                            Url = "https://myapp.mydomain.com/statuslistener.php",
                                            NotRequiredAfterFirstOccurrence = true
                                        }
                                    }
              }

A completed participant from that uses the above code would see something like the following as the posted status notification values:

TransID=1234567890&PartID=1234567890&TXStatus=2&PartStatus=4&EventType=session-begin&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Likewise, if the participant was using a SubscribeToSessionStartNotificationsByGet method type, the posted status notification value might look something like this:

https://myapp.mydomain.com/statuslistener.aspx?TransID=1234567890PartID=1234567890&TXStatus=2&PartStatus=4&EventType=session-begin&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Authentication Failure ​

You can subscribe to Participant authentication failure events by adding a Workflow Action to the Participant.

The data elements sent in the GET or POST are all the common data elements plus the following:

NameValue
EventTypeparticipant-auth-failure-notify
csharp
participant = new ParticipantInsertModel()
            {
                FullName = "John Smith",
                EmailAddress = "testing@alphatrust.com",
                SendRequestViaEmail = true,
                WorkflowActions = new List<object>
                {
                    new ParticipantWorkflowActionModel()
                    {
                        Type = ParticipantWorkflowActionModel.TypeEnum.SubscribeToAuthenticationFailureNotificationsByPost, // or ...ByGet
                        Data = "required-response-text=RECEIVED;retry-limit=1440",
                        Url = "https://myapp.mydomain.com/statuslistener.php"
                    }
                }
            }

A completed participant from that uses the above code would see something like the following as the posted status notification values:

TransID=1234567890&PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-auth-failure-notify&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Likewise, if the participant was using a SubscribeToAuthenticationFailureNotificationsByGet method type, the posted status notification value might look something like this:

https://myapp.mydomain.com/statuslistener.aspx?TransID=1234567890PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-auth-failure-notify&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Participant Reassigned ​

You can subscribe to Participant reassigned events by adding a Workflow Action to the Participant.

The data elements sent in the GET or POST are all the common data elements plus the following:

NameValue
ReassignedPartIDThe ReassignedPartID is a standard 10 digit ID used for a participant that all the tasks will be reassigned to and will be a NEW participant that was created during the reassigning workflow action.

Example: 1234567890
EventTypeparticipant-reassigned
csharp
participant = new ParticipantInsertModel()
              {
                  FullName = "John Smith",
                  EmailAddress = "testing@alphatrust.com",
                  SendRequestViaEmail = true,
                  WorkflowActions = new List<object>
                                    {
                                        new ParticipantWorkflowActionModel()
                                        {
                                            Type = ParticipantWorkflowActionModel.TypeEnum.SubscribeToReassignedNotificationsByPost, //or ...ByGet
                                            Data = "required-response-text=RECEIVED;retry-limit=1440",
                                            Url = "https://myapp.mydomain.com/statuslistener.php"
                                        }
                                    }
              }

A completed participant from that uses the above code would see something like the following as the posted status notification values:

TransID=1234567890&PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-reassigned&ReassignedPartID=1234567891&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Likewise, if the participant was using a SubscribeToStatusChangeNotificationsByGet method type, the posted status notification value might look something like this:

https://myapp.mydomain.com/statuslistener.aspx?TransID=1234567890PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-reassigned&ReassignedPartID=1234567891&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Experian Precise ID Victim Statement ​

You can subscribe to Experian Precise ID Victim Statement events by adding a Workflow Action to the Participant.

The data elements sent in the GET or POST are all the common data elements plus the following:

NameValue
VictimStatementString of text returned by Experian for the victim statement.
EventTypeparticipant-reassigned
csharp
participant = new ParticipantInsertModel()
              {
                  FullName = "John Smith",
                  EmailAddress = "testing@alphatrust.com",
                  SendRequestViaEmail = true,
                  WorkflowActions = new List<object>
                                    {
                                        new ParticipantWorkflowActionModel()
                                        {
                                            Type = ParticipantWorkflowActionModel.TypeEnum.SubscribeToPreciseIdVictimStatementNotificationsByPost, //or ...ByGet
                                            Data = "required-response-text=RECEIVED;retry-limit=1440",
                                            Url = "https://myapp.mydomain.com/statuslistener.php"
                                        }
                                    }
              }

A completed participant from that uses the above code would see something like the following as the posted status notification values:

TransID=1234567890&PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-victim-statement-notify&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Likewise, if the participant was using a SubscribeToPreciseIdVictimStatementNotificationsByGet method type, the posted status notification value might look something like this:

https://myapp.mydomain.com/statuslistener.aspx?TransID=1234567890PartID=1234567890&TXStatus=2&PartStatus=4&EventType=participant-victim-statement-notify&ps_securitytoken=4bf44fb0-f695-40b5-821d-c22273e11c30

Copyright © 1998-present AlphaTrust