How to Send WhatsApp OTP with Node.js Without Exposing API Keys

A weak OTP implementation often focuses only on sending a six-digit code. In production, the harder parts are key secrecy, replay protection, expiry, throttling, auditability, and a clear recovery path when the user does not receive the code. If the frontend calls the OTP provider directly, the API key becomes public. If the app stores raw OTP codes, a database leak turns short-lived verification into a security incident.

DNZ WhatsApp OTP gives you the delivery layer through the real `/api/send-otp` engine route. Your application remains responsible for authentication state: generating the code, hashing it, expiring it, limiting retries, and deciding when the user becomes verified. This split keeps the messaging system reusable while letting each application enforce its own security rules.

Use two endpoints in your own backend. The first endpoint receives a phone number or user ID, checks whether the request is allowed, generates an OTP, stores a hash with an expiry time, and calls DNZ. The second endpoint receives the code typed by the user, compares it with the stored hash, checks expiry and attempt count, then marks the login or transaction as verified.

Keep `WHATSAPP_OTP_ENGINE_URL` and `WHATSAPP_OTP_API_KEY` in server environment variables. The DNZ engine expects `apiKey`, `number`, and `message` in the JSON body. The route returns `202` with `{ accepted: true, jobId }` when the message is queued. That means the API accepted the send job; it does not mean the user has already verified the code.

Start by normalizing phone numbers to E.164 format where possible. Rate-limit by user ID, phone number, and IP address. Generate six random digits with a cryptographic random source, never with `Math.random`. Store a hash of the OTP, not the raw code. A five-minute expiry is common for login; payment confirmation can be shorter if your risk model requires it.

When verifying, compare hashes using a constant-time comparison where practical, increment failed attempts, and delete or invalidate the OTP after a successful verification. If you allow resend, create a resend cooldown so users cannot accidentally queue many WhatsApp messages or trigger platform abuse systems.

Handle DNZ errors explicitly. `400 missing_fields` means your backend sent an incomplete payload. `400 invalid_number` means the normalized number is too short. `401 invalid_api_key` means the API key is wrong or inactive. `429` means a rate or plan limit blocked the message. A `500 send_otp_failed` should be logged and shown to the user as a temporary delivery issue.

On the UI, do not tell users whether a phone number belongs to an existing account unless your product requires it. A neutral message such as 'If this number can receive verification, a code will be sent' reduces account enumeration risk. For logged-in payment confirmations, you can be more specific because the user is already authenticated.

After the Node.js integration is working, review the API reference for exact request and response fields, then test one frontend flow such as React or Flutter through your own backend. Keep the DNZ dashboard open during testing so you can compare application logs with queued jobs and plan limits.

For production launch, connect your monitoring to request failures, OTP verification failures, and unusual resend volume. OTP is a security workflow, so treat delivery metrics and abuse metrics as part of the same system.