Keep your existing WhatsApp provider when the connector lands

Everything a recruiter does with WhatsApp in the product is provider-agnostic by design. The composer, the session window countdown, the template picker, opt-in capture, STOP suppression, the reply handler and the flow runner all sit above the router. The provider underneath is a tenant configuration.

So adding Gupshup would not give a desk a new feature. It would let a desk that already sends through Gupshup keep doing so while getting the recruitment workflow on top. Nobody switches to Surhires to get Gupshup; a firm already on Gupshup avoids a migration.

That distinction is worth stating because integration pages tend to imply that each new logo unlocks something. Here it does not, and pretending otherwise would misrepresent both the roadmap and the product.

The reasons are commercial and operational rather than technical, and they are legitimate. A firm may have a negotiated rate card that a smaller organisation cannot get by going direct. It may have an account manager who resolves delivery problems in an hour rather than through a support queue. It may be inside a contract term with a minimum commitment.

The template library is the other reason, and it is underrated. An established sender has dozens of approved templates in multiple languages, each of which took a submission cycle to get through review. Those approvals live with the WhatsApp Business Account and the provider tooling around it, and rebuilding them is a project measured in weeks, not an afternoon.

Add the number itself, the display name, the quality rating built up over months, and the case for keeping a provider becomes obvious.

Three routing paths ship: Meta Cloud API directly, Twilio, and DoubleTick. Any of them can carry an India-market desk today, and the recruitment workflow is identical across all three.

If you are starting fresh, going direct through the Meta Cloud API with your own WhatsApp Business Account is usually the simplest arrangement, and the one with the fewest parties between you and delivery. If you already run Twilio for voice, using the same credentials for WhatsApp keeps the account count down.

If you are on Gupshup today and unwilling to move, the honest answer is that the connector is not built yet and you should weigh that in an evaluation rather than being told it is coming soon.

Whichever of the three routes carries the traffic, the recruitment side is unchanged. A WhatsApp thread sits on the candidate record beside the submittals, the interview history and the disposition codes. A reply moves a stage or raises a task. A follow-up nudge cancels itself the moment the candidate answers. The router is plumbing; the workflow above it is the reason to put WhatsApp inside recruitment software at all.

What would change: your tenant configuration names Gupshup, sending goes out over your Gupshup account, and your billing stays with Gupshup at your rates. Your approved templates map into the product's template library rather than being re-submitted.

What would not change: the 24-hour session window rules, because those are Meta's and no provider changes them. Template approval still comes from Meta, granted to your business rather than to us or to Gupshup. Opt-in still has to be captured and recorded. STOP still suppresses tenant-wide.

Anyone suggesting a provider makes those obligations go away is selling something. The rules belong to the platform.

If Gupshup moves into build it will be described as in development, in the future tense, with the scope named. When it ships it will carry an evidence line naming the routing function, in exactly the way the WhatsApp page names its stack today.

There is no partnership with Gupshup, no certification, no reseller arrangement and no listing. If one ever exists it will be stated plainly and dated. Until then this page is what a roadmap item looks like when it is written honestly.