Knowledge Base

⌘K
  1. Home
  2. Docs
  3. Knowledge Base
  4. Webhooks
  5. Webhook Actions
  6. Set Up a Webhook Action

Set Up a Webhook Action

About Webhook Notifications

An Apptoto Webhook Action is simply a HTTP POST request made from Apptoto’s servers to an URL endpoint of your choosing. A Webhook Action can transmit data from Apptoto across the web to another system or third party product and is a powerful tool that can be used for reporting purposes or integrating services with Apptoto.

Setup

To setup a Webhook Action to respond to triggers, click the Webhook “add” button in the Webhook Triggers section under the trigger form after creating a trigger or clicking a trigger’s settings button:

Click +Add to add a webhook action after setting up a trigger

This will result in a new form rendering below the trigger form that allows you to configure a Webhook Action:

enter details for the webhook action you want to take place after a trigger

To setup a Webhook Action, select “Send webhook notification” under the “Webhook Action Type” field. Upon selecting this value, a “Webhook URL” field appears; this field stores the web endpoint (e.g. an API endpoint or a Zapier URL) that the Webhook Trigger will attempt to reach when the trigger executes. As with any of the other types of Webhook Triggers, a name field is provided so that you can assign an identifier to the Webhook Action and easily find it later.

Webhook Action Payloads

When a Webhook Action occurs as a result of a trigger being triggered, Apptoto will make a HTTP POST request to the endpoint specified in the Webhook Trigger settings. When this happens, the HTTP request is accompanied with information stored in a JSON format about the object that the trigger is based on, as well as an identifier that corresponds to the instance of the Webhook Action running. The exact structure of this payload depends on the type of trigger that the Webhook Action corresponds to (e.g. a Webhook Action for an event-based trigger will contain information regarding an event, where a Webhook Action setup for a message-based trigger will send information relating to a message.) The exact structure of the payload for individual triggers are as follows:

Event-Based Triggers (“New event is created”, “Event is updated”, “Event is deleted”):

JSON AttributeDescription
eventEvent object (object)
idEvent ID (integer)
calendar_idCalendar ID (integer)
calendar_nameCalendar name (string)
external_idExternal Event ID (string)
start_timeEvent start time (date)
end_timeEvent end time (date)
all_dayAll day (boolean)
titleEvent title (string)
locationEvent location (string)
contentEvent content (string)
participants(array of objects)
idParticipant ID (integer)
event_idEvent ID (integer)
display_nameParticipant display name (string)
nameParticipant name (string)
phoneParticipant phone (string)
normalized_phoneParticipant normalized phone number (string)
emailEmail for participant (string)
stateReminder state or booking state (string)
custom_dataCustom data properties for event (object)
is_deletedIndicates if event has been deleted (boolean)
apptoto_idUnique identifier for webhook (string)

Participant-Based Triggers (“Participant reminder state changed”, “Participant confirmed”, “Participant not coming”, et al.)

JSON AttributeDescription
participantParticipant object (object)
idParticipant ID (integer)
event_idEvent ID (integer)
display_nameParticipant display name (string)
nameParticipant name (string)
phoneParticipant phone (string)
normalized_phoneParticipant normalized phone (string)
emailemail (string)
eventEvent object (object)
idEvent ID (integer)
calendar_idCalendar ID (integer)
calendar_nameCalendar name (string)
external_idEvent external ID (string)
start_timeEvent start time (date)
end_timeEvent end time (date)
all_dayEvent is all day (boolean)
titleEvent title (string)
locationEvent location (string)
contentEvent content (string)
custom_dataCustom field information (array of objects)
is_deletedEvent has been deleted (boolean)
apptoto_idUnique identifier for webhook (string)

Booking Page-Based Triggers (“Booking Page is viewed”)

JSON AttributeDescription
booking_pageBooking page object (object)
idBooking page ID (integer)
nameBooking page name (string)
urlBooking page URL (string)
apptoto_idUnique identifier for webhook (string)

Booking Request-Based Triggers (“Booking request is completed”)

JSON AttributeDescription
booking_requestBooking request object (object)
tokenBooking request token (string)
stateBooking request state (string)
appointment_type_tokenAppointment type token (string)
occurrence_selected_event_idEvent ID of occurrence selected (integer)
start_timeBooking start time (date)
end_timeBooking end time (date)
sign_up_pageBooking page is sign up page (boolean)
timezoneContact timezone (string)
field_dataCustom field data (object)
contact_infoContact info object (object)
nameContact name (string)
phoneContact phone (string)
emailContact email (string)
booking_page(object)
idBooking page ID (integer)
nameBooking page name (string)
urlBooking page URL (string)
apptoto_idUnique identifier for webhook (string)

Message-Based Triggers (“Message sent”, “Message received”)

JSON AttributeDescription
messageMessage object (object)
idMessage ID (integer)
participantParticipant object (object)
idParticipant ID (integer)
event_idEvent ID (integer)
display_nameParticipant display name (string)
nameParticipant name (string)
phoneParticipant phone (string)
normalized_phoneParticipant normalized phone (string)
emailParticipant email (string)
stateParticipant reminder/ booking state (string)
startedMessage started sending at (date)
comm_typeCommunication type (string)
last_outLast message out (date)
last_inLast message in (date)
apptoto_idUnique identifier for webhook (string)

Phone number is added to stoplist

JSON AttributeDescription
phonephone number (string)
apptoto_idUnique identifier for webhook (string)

Email is added to stoplist

JSON AttributeDescription
emailemail (string)
apptoto_idUnique identifier for webhook (string)

Logging

For each Webhook Action setup, you can view instances of the Webhook Action by clicking the “Log” button:

View instances of the Webhook Action by clicking the “Log” button

For a Webhook Action, this will return a table listing the instances in reverse chronological order, with their corresponding state or status, indications of whether the Webhook Action was successfully sent from Apptoto and delivered (received by target system), number of attempts, as well as means of inspecting the payload and response for each instance. You can also filter logs based on whether or not the Webhook Action is successful, as well as sort the table by individual columns.

View whether Webhook Action was successsful via the Log

Webhook Action Attempts

Webhook Actions in Apptoto are different from other types of Webhook Triggers in the sense that failed Webhook Actions will retry in certain circumstances.

In Apptoto, a Webhook Action is considered successful when a HTTP 200 response is returned from the server that Apptoto is doing a POST request against.

If the resource that Apptoto is posting against encounters a 500 series error (e.g. a 500 internal server error or a 502 bad gateway error), Apptoto assumes that the problem might be temporary and will retry the request again up to five attempts.

If a 400 series error is returned when the Webhook Action request is made (e.g. a 403 forbidden error or a 404 not found error), Apptoto will assume that a configuration error was made when setting up the webhook or that the webhook endpoint isn’t valid and thus the request instance should not be reattempted.