Event Notification (webhooks) Concept
- Event Notifications adhere to the concept of "Request" and "Response".
- The "Request" in the case of Event Notifications is triggered by the recipient via them performing a specific operation, i.e. clicking a link.
- This "Event" trigger is interpreted by our system, updating the associated entity, i.e. report.
- The configured "Event" process is then chosen to return this "Event" data, i.e. via email.
These are the type of events that can be used as triggers for event data within the platform.
Each of these can have a single type of destination, but can be configured independently from one another.
i.e. an OPEN trigger can be set to CLIENT PULL, and the CLICK trigger can be configured to HTTP POST
|DELIVERYSTART||A campaign reaches the scheduled date time and begins processing|
|DELIVERY||A campaign has finished processing and is being sent out (not indicative of completion of sending)|
|OPEN||A recipient opens an email and either views the images or clicks the links|
|CLICK||A recipient clicks a link in an email|
|BOUNCE||A hard bounce response is received from the email recipient|
|BLOCKED||A blocked response is received from the email recipient|
|OPTIN||A recipient opts in to a profile via a signup form that uses the list builder interface.
doubleOptin not set to FALSE in the signup request.
A custom email with a signup confirmation code snippet.
A signup automation linked to the target list and confirmation message.
If you have any questions please either contact email@example.com, or your customer success manager.
|OPTOUT||A recipient opts out of a profile via an unsubscribe link in an email campaign that uses a default/custom landing page that is connected to our system|
|SOFTBOUNCE||A soft bounce response is received from the email recipient|
|SMSOPTOUT||An SMS record opts out of a profile|
|SMSFAILED||A bounce response is received from the SMS recipient|
These are where to send these call backs to with the event data based on the trigger.
|Client Pull||Use the SOAP API to batch retrieve these events in an associative array (map) via the bus_facade_eventNotification. Batch size for each request is upto 10,000 event records. During the retrieval process marking the batch as read removes them from the system, allowing the collection of the next batch|
|The data is placed in a simple email which is triggered to a specified address. Ideal if the integrating system can update via email, however if sending to a large number of recipients this will not be ideal for, for instance, an employee's inbox|
|HTTP||From a specific IP address the system will send a POST data array to a defined location where a listener process can validate and parse these requests.|
It's expected a success response message (i.e. an "OK" response reply) to be sent back to the requesting location to verify this POST array has been recieved. If this reply isn't sent the sending servers will attempt to send the data up to five times before giving up. There will be duplicates if this is omitted. HTTP POST is not recommended for any user that is sending 500k emails or more per week.
|FTP||The POST data is configured into a string, written to a log that is periodically be uploaded to a defined FTP location. SFTP locations are not currently supported. You may consider this as a daily logging option.|