No code · v1

CleverTap & WebEngage

If you already run campaigns from CleverTap or WebEngage, you do not need to move them. Add QuickAuth as your WhatsApp provider inside the platform you use, and keep building journeys where you build them today — QuickAuth becomes the carrier underneath, and delivery reports flow back so their reporting stays accurate.

Let your coding assistant do this

Claude Code, Cursor, Copilot and Windsurf can wire this up for you. The prompt below points them at our integration guide, which carries every endpoint with its real field names, status codes and response shapes rather than a summary they have to guess at.

prompt

Read https://quickauth.in/llms-full.txt — it is QuickAuth's integration guide, with the real endpoint paths, field names and response shapes. Then add the QuickAuth WhatsApp provider integration to this project, following the conventions already in the codebase. Keep the client id and secret in environment variables and never in client-side code.

Open in Claude Open in ChatGPT Read the guide

You write no code for this

Everything below is configuration in someone else’s dashboard plus one webhook in ours. The API pages are for building something yourself; this page is for connecting two products you already have.

What you need first

A QuickAuth account with a connected WhatsApp number.
Your X-Client-Id and X-Client-Secret from dashboard.quickauth.in. The secret is shown once.
Templates approved on both sides — the platform sends a template by name, and QuickAuth has to hold an approved template with that name.

WebEngage

WebEngage calls this a private BSP. In their dashboard, add QuickAuth as your WhatsApp provider and point it at:

Endpoint

https://api.quickauth.in/v1/webengage/whatsapp

Custom headers:
  X-Client-Id:     <your client id>
  X-Client-Secret: <your client secret>

That is the whole send path. QuickAuth answers immediately with their accept contract, then sends the message and reports the outcome back.

Delivery reports back to WebEngage

In the QuickAuth dashboard, open Webhooks and add one:

Destination — WebEngage
URL — the delivery-report callback from your WebEngage onboarding manager
Security token — only if your endpoint was issued one; many carry the account in the URL instead, and then you leave it blank
Events — the three delivery.* events

CleverTap

CleverTap calls this a Generic provider. Under WhatsApp provider settings, choose Generic (Other) and fill in:

Provider configuration

Nickname          QuickAuth
Request Type      POST
HTTP End Point    https://api.quickauth.in/v1/clevertap/whatsapp
Body              JSON  (payload version 0.1)

Authentication — custom headers:
  X-Client-Id:     <your client id>
  X-Client-Secret: <your client secret>

Delivery Report Callback URL
  https://cb.wzrkt.com/wa/generic/status?a=<your project id>

Inbound Message Callback URL
  https://cb.wzrkt.com/wa/generic/response?a=<your project id>

CleverTap tests the endpoint when you save

Saving the provider sends a probe and expects a success within a second. If something is wrong it shows you the request and response — and because QuickAuth answers in CleverTap’s own error format, a wrong credential reads as invalid credentials rather than as the endpoint being down.

Delivery reports back to CleverTap

Same place — Webhooks in the QuickAuth dashboard. Choose CleverTap as the destination and paste the status callback URL above. No token: their URL already carries your project id, which is what identifies you.

What each side is responsible for

Concern	Where it lives
Audience, journeys, scheduling	CleverTap / WebEngage
Template content and approval	Both — the names must match
Sending, retries, WABA routing	QuickAuth
Billing and delivery analytics	QuickAuth
Campaign reporting	The platform, from our delivery reports

A partner endpoint only receives its own messages

If you connect both platforms, each one is told only about the messages it sent. A CleverTap endpoint never hears about a WebEngage send — the message id would mean nothing to it. Your own webhooks still receive everything.

If a send is rejected

Both integrations answer in the platform’s own error vocabulary, so the reason shows up in their UI rather than as an opaque failure. The two that account for most first-day problems:

Template not found — the platform is sending a template name QuickAuth has no approved template for. Names must match exactly.
Variable count mismatch — the template expects three values and the campaign sends two. We refuse rather than pad, because padding delivers a message with a blank where the customer’s name should be.