Page Comparison

...

"email_sent_to_client":{ //notification id, we will reference it in the workflow
  "media":{
    "webhook_topic":[
      "email_sent_to_client_topic" //topic id, we will thethen create it through API
    ]
  },
  "time_type": "duration",
  "time_value": "0s"
}

...

• Prevent Queue Blocking: By acknowledging based solely on signature validation, the message queue remains smooth and uninterrupted.

• Efficient Processing: Additional content checks can be handled asynchronously, avoiding potential bottlenecks.

5. Retries

...

, Error Management and Alerts

If acknowledgment is not received within the configured time frame, the system will retry sending the message. Notifications regarding errors can be sent via SMS, email, or both.

Reponse StatusesEvents :

1. on_failure: Triggered after the maximum number of retries (retries_until_failure) is reached without acknowledgment. This indicates that the message failed to be deliveredRetries count do not include the original message (the first one which was not ackowledged).

2. on_failure_recovered: Triggered when a failed message is later acknowledged during a retry. The retry count resets to 0.

3. on_deactivation: Triggered when the maximum retry attempts are exhausted without recovery. The webhook is automatically disabled and must be manually reactivated.

...

PATCH /webhooks/:id/status 
{ "site_id": "{{site_id}}", "token": "{{token}}", "status": "enabled" }

Alerts

...

Emails and SMS are sent to notify webhook events stated above.

This are configured in the site configuration

 "on_failure": {
    "contact_emails": [ //email alert recipients. In test environments emails are sent to test recipients set in Configuration/Outbound/Media/Test Emails
      "email@company.com"
    ],
    "contact_mobiles": [],
    "sms_notification_name": "",
    "email_notification_name": "webhook_failure" //do not change
  },
  "on_deactivation": {
    "contact_emails": [ //email alert recipients. In test environments emails are sent to test recipients set in Configuration/Outbound/Media/Test Emails
      "email@company.com"
    ],
    "contact_mobiles": [],
    "sms_notification_name": "",
    "email_notification_name": "webhook_deactivation" //do not change
  },
  "on_failure_recovered": {
    "contact_emails": [ //email alert recipients. In test environments emails are sent to test recipients set in Configuration/Outbound/Media/Test Emails
      "email@company.com"
    ],
    "contact_mobiles": [],
    "sms_notification_name": "",
    "email_notification_name": "webhook_failure_recovered" //do not change
  }

6. Webhook Statuses

• enabled: The default state after creation. Messages are processed normally, triggering the webhook.

• Paused: Messages are stored while the webhook is in a paused state. The behavior of this state depends on the scenario:

  • Manual pause: No messages will be sent until the webhook is manually re-enabled.

  • Automatic pause: This occurs when a message is not acknowledged by the receiver within 15 seconds. In this case, the message will be retried. If the message fails to be acknowledged after the configured number of retries (retries_until_failure), an on_failure notification will be triggered (via email and/or SMS, depending on configuration). If the maximum number of retries is reached without success, the webhook will be disabled. However, if the message is acknowledged before reaching the retry limit, the webhook will automatically resume sending messages (enabled).

• disabled: The webhook stops functioning and storing messages after an on_deactivation error. It must be manually reactivated.

...