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. Copy the prompt into your assistant: it points it at our API guide (every endpoint with its real fields and error codes) and spells out the rules integrations most often get wrong.

prompt · Phone OTP login

Read https://quickauth.in/llms-full.txt first — it is QuickAuth's API guide with the real endpoint paths, field names, response shapes and error codes. Then add phone-number OTP login to this project, following the conventions already in the codebase.

Rules:
- Keep X-Client-Id and X-Client-Secret in server-side environment variables, never in client code.
- Send the code with POST /v1/auth/initiate and check it with POST /v1/auth/verify from the server.
- A wrong code is HTTP 200 with verified:false — show "attempts remaining"; OTP_EXPIRED and MAX_ATTEMPTS_EXCEEDED mean start again.
- If the code is checked in the app through a QuickAuth SDK, confirm the requestId on the server with POST /v1/auth/verify-code and sign in the phoneNumber it returns.
- Branch on errorCode, not message (error codes: https://quickauth.in/docs/errors).

Add tests for the error paths, and tell me which environment variables to set.

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, under Settings → API credentials. 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. The name to use is the template’s Meta name: your template name lower-cased, with spaces and hyphens turned into underscores and any other character dropped (Order Shipped-v2 → order_shipped_v2).
If the platform sends a sender number (WebEngage fromNumber, CleverTap wabaNumber), it must be one of your WhatsApp numbers connected to QuickAuth — anything else is refused.

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 — required. WebEngage webhooks are always sent with Authorization: Bearer <token>; use the token from your WebEngage onboarding manager
Events — the delivery.* events: delivery.sent, delivery.delivered, delivery.read, delivery.failed

WebEngage has no separate “delivered” status, so both sent and delivered are reported as whatsapp_sent; read becomes whatsapp_read and failed becomes whatsapp_failed.

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.

Customer replies need their own webhook. Add a second one with CleverTap as the destination, the inbound message callback URL above, and the message.received event. Only template messages can be sent through CleverTap — a freeform message (isTemplate: false) is refused with error 2004.

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

Delivery reports go only to the platform that sent

If you connect both platforms, each one gets delivery and click reports only for the messages it sent — a CleverTap endpoint never hears about a WebEngage send. Inbound replies are different: message.received goes to every partner endpoint subscribed 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.