- What are Web Hooks?
- How to effectively use Web Hooks
- Example of Web Hooks
Capitalizing on Web Hooks
Web Hooks, known also as Callbacks, are your source of real-time message events. Web Hooks allow you to react to new message events that are unique to your solution. They are fast, reliable, and a basic building block in any API solution.
What are Web Hooks?
As an API customer, you register for the Web Hook Events that you find relevant for your solution. This registration process is done at the line level. Each event can be sent to any number of Web Hook receivers. This means that you have an active/active data center configuration, then each data center receives the Web Hook Event in real-time. This also means that you can dedicate some of your text-enabled lines for your QA environment and your production environment, which makes code changes easier to test.
- Receive – When a new message is received on your text-enabled line
- Send – When a new message is sent from your text-enabled line
- Read – When an inbound message is marked as read
- Delete – When a message has been deleted
- Progress – A status notification as a sent message is delivered to the recipient
Web Hooks contain all the pertinent message event data to act on the message.
We understand that Web Hooks are the ideal way for receiving new message events, so we employ a 72 hour retry mechanism on every Web Hook event.
Leveraging the power of Web Hooks
The real-time nature of Web Hooks is their biggest asset. As a solution implementer, you can react instantly to a customer’s message. By providing the pertinent detail of the message, you’re better able to process the message without delay.
Some common uses of Web Hooks include:
- Storing message Send and Receive events in a database to run business critical metrics on customer interactions.
- Creating dynamic keyword functionality, when the customer sends in ‘Usage’ you send back this month’s data usage for their account.
- Setting up automated appointment reminder confirmations.
Web Hooks pair nicely with the Zipwhip Web App. If your solution can process an inbound message, then it can either mark that message as read, deprioritizing it in the GUI, or delete the message completely. Users of your system or Zipwhip’s Web App see the message and can use the automated responses as reference when interacting with your customers.
Implementation example: taxi cab scheduling
A customer makes a reservation for a taxi to pick them up from their office and drive them to the airport. Prior to dispatching the taxi, the taxi company’s system automatically sends the following text message 15 minutes prior to the scheduled pickup time: “John, your pickup time is 4:00pm, please respond ‘C’ to confirm this reservation.”
As John finishes packing his briefcase, he responds by texting the letter ‘C’. This confirms the ride and the taxi is dispatched. The message with the letter, ‘C’, is automatically marked as read. The Dispatch employee sees that a new interaction took place, but there is no unread notification in the Web App.
Now let’s assume John is not timely. Instead, he’s distracted by a long running board meeting. Assume that when he receives the automatically generated text message, instead of typing ‘C’ to confirm, John types: “No, I need to change the pickup time to 4:15pm.”
The reservation system would recognize the invalid confirmation response and so the message would be tagged with an unread notification in the Web App. The Dispatch employee would see the message, go into the dispatching software, and update the reservation for 4:15. The employee can then send the following response: “Hi John, your reservation has been updated for 4:15pm, have a safe flight!”