Webhook Configuration

There are two methods that are supported for notifying your application of 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.

Event Control Parameters

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

Data Parameters	Status	Description
required-response-text	Active	A 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="required-response-text=RECEIVED;"`
request-timeout	DEPRECATED	~~A 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.~~ This parameter is deprecated and no longer configurable. See Server-Configured Settings below. ~~Example: `Data="request-timeout=60;"`~~
retry-limit	DEPRECATED	A 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. This parameter is deprecated and no longer configurable. See Server-Configured Settings below. ~~Example: `Data="retry-limit=1440;"`~~

Server-Configured Settings

Important Change: As of the latest version, timeout and retry behavior is now configured server-side and cannot be modified by developers. The request-timeout and retry-limit parameters are deprecated and will be ignored if included in your Data property.

The following settings are now configured on the AlphaTrust® e-Sign server and apply to all event subscriptions:

Response Timeout

Fixed Timeout: 10 seconds
Previous Behavior: Configurable from 30-180 seconds via request-timeout parameter
Migration: Remove the request-timeout parameter from your Data property. Ensure your webhook endpoints can respond within 10 seconds.

Retry Schedule

The system now uses a sophisticated backoff schedule for failed webhook deliveries. If your endpoint fails to respond successfully, the system will retry according to this schedule:

Attempt	Delay Before Retry	Cumulative Time
1	5 seconds	5 seconds
2	30 seconds	35 seconds
3	90 seconds	2 minutes
4-6	1 hour each	~3 hours
7-12	1 day each	~9 days
13-16	1 week each	~37 days
17-21	1 month each	~5 months

Total Retry Attempts: 21 attempts over approximately 5 months

Previous Behavior: Configurable retry period via retry-limit parameter (30-10080 minutes), with 5-minute intervals between retries.

Migration: Remove the retry-limit parameter from your Data property. The new schedule provides more aggressive initial retries with longer-term persistence for temporarily unavailable endpoints.

Server Configuration Details

The retry and timeout behavior is controlled by these server-side settings (for reference only - these cannot be modified by developers):

{
    "QueuedActionsBackOffInSeconds": [
        5, 30, 90, 3600, 3600, 3600, 86400, 86400, 86400, 86400, 86400, 86400, 604800, 604800, 604800, 604800, 2592000, 2592000, 2592000, 2592000,
        2592000
    ],
    "QueuedActionsResponseTimeoutInSeconds": 10
}

Migration Guidelines

If you are currently using the deprecated parameters:

Remove deprecated parameters: Remove request-timeout and retry-limit from your Data property strings
Optimize endpoint performance: Ensure your webhook endpoints respond within 10 seconds
Update error handling: Account for the new retry schedule in your webhook processing logic
Test thoroughly: Verify your integration works with the new timeout and retry behavior

Example Migration

Before (Deprecated):

Data = "required-response-text=RECEIVED;request-timeout=60;retry-limit=1440"

After (Current):

Data = "required-response-text=RECEIVED"

Best Practices

Immediate Acknowledgment Pattern: Accept webhook requests immediately and respond with success status, then queue the event data for asynchronous processing. This decouples webhook receipt from business logic execution and ensures fast response times.
Fast Response: Design your webhook endpoints to respond within 10 seconds
Idempotent Processing: Ensure your webhook can safely process duplicate events due to retries
Error Logging: Log webhook failures for debugging since retries will continue for months
Health Monitoring: Monitor your webhook endpoint availability to minimize failed deliveries