Skip to content
On this page

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


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.

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;"

Status Change

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

The data elements sent in the GET or POST are:

TransIDThe TransID is a standard 10 digit ID used for a transaction as discussed elsewhere. Example: 1234567890
TXStatusThe TXStatus will be one of the following one-digit integer values:
  • 2 Pending
  • 4 Complete
  • 7 Closed
  • 8 Cancelled
  • 9 Expired
  • 10 Voided


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

transaction = new TransactionCreateModel()
                  WorkflowActions = new List<object>
                                        new TransactionWorkflowActionModel()
                                            Type = TransactionWorkflowActionModel.TypeEnum.SubscribeToStatusChangeNotificationsByPost, //or ...ByGet
                                            Data = "required-response-text=RECEIVED;retry-limit=1440",
                                            Url = ""

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


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