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.

Event Triggers

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

Type Description
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.
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

Event Process

These are where to send these call backs to with the event data based on the trigger.

Type Description
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
Email 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.
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.