HopGuard™
Your business runs on your number. Add a layer of protection.
HopGuard™ adds a layer of protection by controlling the rate your number sends at. Included on paid channels at no extra charge. Not on the free sandbox. WhatsApp's decisions stay WhatsApp's.
Your customers know your number and your team works through it. HopGuard™ gives the code that sends from it a queue, gaps between messages, and a pause for serious failures.
Included on paid channels. Built in. One switch.
Included on paid channels at no extra charge.
Sends may take longer while it's on or the queue is draining.
When your code gets ahead of your intentions.
You meant to send a useful message. Then a worker restarted, a campaign went live, or a login disappeared. The question is what your sender does next. HopGuard™ gives your sends a queue with rate control, so your application does not have to build that part itself.
The retry loop that keeps going
Imagine a retry loop submitting the same message again and again after an error. HopGuard™ does not stop the loop or drop the duplicates; that stays your code's job. It changes the shape: every accepted request goes into the channel queue and leaves one at a time, with gaps, so a runaway loop becomes spaced sends instead of a burst while you fix it.
The campaign that arrives all at once
Your application releases a campaign in a burst. HopGuard™ puts accepted sends into the queue, then spaces the attempts out. Messages to the same person keep the order they were accepted into the queue, even when the queue contains messages for other people too.
The lost login with work still waiting
A queued send reaches a serious failure, such as a lost login. HopGuard™ pauses the queue so the rest wait instead of following it. A failed queued send reports its result through a webhook, giving your application something concrete to respond to.
Sending discipline, already built.
Covers text, contact cards, polls, and media sent by URL.
Bursts become a queue
Supported API sends go into a channel queue. HopGuard™ sends them one at a time. A burst from your app becomes queued work, not a burst of send attempts.
Sends spaced out for you
The queue leaves a gap between send attempts. Your application submits the message; the channel handles the spacing.
Slower first contact
First contacts go slower than replies and may wait while replies can continue. HopGuard™ does that in the queue, so your sender does not have to treat every conversation the same way.
Same person, same order
Messages to the same person keep their accepted queue order. Once the introduction is accepted into the queue, submit the follow-up; the queue keeps that accepted order for the same person.
A pause for serious failures
A serious failure, such as a lost login, pauses the queue. Other failed sends report their result by webhook; only serious ones pause the queue. HopGuard™ never resends for you.
Off until you choose
HopGuard™ is optional and off by default. Turn it on for the channel you choose. That choice belongs to you, whether you use the console or your channel's API.
Built in, or built by you.
A queue is only part of the work. There is also spacing, different treatment for first contact, accepted queue order within a conversation, and deciding when a serious failure should stop the rest. Choose whether you want to build and maintain those controls yourself.
Without HopGuard™
You build and maintain it yourself: the queue, the gaps, the first-contact controls, the accepted queue order per person, and the serious-failure pause in your own sender.
With HopGuard™
Built in, one switch: turn it on for your channel and use the supported message endpoints. Part of HelloHop, at no extra charge.
For the messages your business sends.
Use HopGuard™ where your application sends messages to people who agreed to hear from you.
Customer updates
Send text updates about an order or an appointment. When your app submits a burst of updates, the queue spaces accepted sends out. Messages for the same person keep the order they were accepted into the queue.
Sales follow-ups
Send an introduction as text. Once it is accepted into the queue, submit a contact card with the details your customer asked for. The queue keeps that accepted order for the same person, and first contacts go slower than replies.
Feedback requests
Send a poll to people who agreed to give feedback. Poll sends use the same channel queue, so your application can submit the requests while the queue spaces the sends.
Documents and media
Send a document, image, or other supported media using a URL. It enters the queue alongside supported text, contact cards, and polls. Media goes in by URL while HopGuard™ is on.
Choose it for your paid channel.
HopGuard™ is included on paid channels at no extra charge. Not on the free sandbox. Choose the paid channel where you want the controls and turn it on there. Enabling it on a channel is an explicit choice, not something signup does for you.
Open your channel's menu, choose Turn HopGuard™ on, and select Turn on to confirm. The console asks you to confirm the change before it takes effect. You can turn it off from the same menu.
Turning it off lets the existing queue drain with gaps between sends. Once the queue is drained and the setting is off, sends use the regular API behavior. You decide which channels use these controls.
Open the consoleSame send endpoints. One setting, one new response to handle.
With HopGuard™ on, a supported send accepted into the queue returns a queued response. The result arrives later by webhook. Your application should handle that later result rather than treating the queue response as delivery confirmation.
Enable on your channel, then submit a message
PUT /pacing
{"mode":"on"}
POST /messages/text
{"to":"RECIPIENT","text":"Hello"}
202 {id, status:"queued", position}Before you turn it on.
Is HopGuard™ an extra charge?
No. Included on paid channels at no extra charge. Not on the free sandbox. HopGuard™ is optional; you choose whether to enable it for each paid channel.
Is it enabled when I sign up?
No. It is off by default. Open your channel's menu, choose Turn HopGuard™ on, and select Turn on to confirm.
Which messages does it cover?
Text, contact cards, polls, and media sent by URL.
What happens if I turn it off?
The existing queue drains with gaps between sends. With the queue drained and HopGuard™ off, sends use the regular API behavior.
How does my application get the result?
A supported send accepted into the queue gets a queued response. The result arrives later as a webhook event; the queue response itself is not delivery confirmation.
Put sending discipline behind your number.
Bring the messages your customers asked for. Let HopGuard™ run the queue, the gaps, and the accepted queue order per person. Included on paid channels, built in, and off until you switch it on.