How WhatsApp Authentication Templates and App Review Work

Direct answer

A WhatsApp authentication template must be approved before it is used for a business initiated one time password message. Meta App Review is a different check. It applies to the permissions and access model of your Meta app, especially when your software manages WhatsApp assets or sends messages for business customers. Creating an authentication template does not by itself prove that your app needs or has passed App Review.

Start by asking two questions. Does the template meet WhatsApp rules for authentication messages? Does the Meta app have the permissions required for the businesses and assets it will operate? Check both, because passing one does not pass the other.

Understand the two approval paths

Template approval checks a specific message template. WhatsApp says a business may initiate a conversation only with an approved template and may review, approve, pause or reject it. Read the current WhatsApp Business Messaging Policy before submission.

App Review checks how a Meta app uses permissions. A company sending for its own WhatsApp Business Account and a technology provider operating for customer businesses do not necessarily follow the same permission path. The required permissions and review evidence depend on the app model, access level and assets involved.

Do not describe a template status of APPROVED as proof that an app has Advanced Access. Do not describe an approved app permission as proof that every future template will be approved.

Decide whether App Review applies

Use the Meta developer dashboard as the source of truth for the app you control. List each permission, whether access is standard or advanced, whose WhatsApp Business Accounts are managed and which action the app performs.

For a technology provider, review evidence commonly separates two actions. Messaging permission evidence shows the app sending a WhatsApp message that arrives on a real WhatsApp interface. Management permission evidence shows the app creating or managing a message template. The Twilio provider integration guide documents this separation for its provider workflow.

Record a clean demonstration with test data, visible navigation and one permission purpose at a time. Never expose access tokens, customer data or private account identifiers in the recording.

Build the authentication template correctly

Authentication templates are for one time passcodes used in login, registration or account recovery. Keep the message focused on verification. Do not turn the authentication category into a marketing message or add unrelated promotional copy.

Meta's official template collection shows that creation uses the WhatsApp Business Account message templates endpoint and the AUTHENTICATION category. Its examples include a body with a security recommendation, an expiration notice and an OTP button.

Use a stable template name and create a separate language version for every language you will actually send. Treat the expiration note as customer guidance, not as proof that your own server has invalidated the code. Your authentication service must enforce code expiry and single use independently.

Choose copy code or one tap

A copy code template gives the customer a button that copies the verification code. Meta's copy code example uses an OTP button with the COPY_CODE type. It is the simpler option when you need a broad device path or do not control an Android app.

A one tap template can pass the code into a matching Android app after the customer taps. Meta's one tap example includes the Android package name and signing hash. Use the release package and release signing identity, not a debug value. Keep copy code as the expected fallback when the app match is unavailable.

Choose from the customer journey, not from novelty. A reliable copy action is better than autofill that works only in a test build.

Create and submit the template

1. Confirm the WhatsApp Business Account and phone number that will own the template.
2. Choose AUTHENTICATION and one clear login, registration or recovery use case.
3. Select copy code or one tap based on the supported client experience.
4. Add only the supported security and expiry components you can enforce.
5. Create every required language version with natural wording.
6. Submit the template and store its identifier, category and review status.
7. Do not send production traffic until the status is approved and the exact language version is available.

In DripTell message templates, keep the approved template name, language and purpose aligned with the workflow that sends it. Approval is a gate, not a guarantee that delivery or verification succeeded.

Test the complete verification path

Test template approval, message delivery and code verification as separate stages. Use test recipients and nonproduction codes. Confirm success, delayed delivery, expired code, reused code, wrong code, unavailable autofill, copy fallback and too many attempts.

The send API accepting a request means the request entered the platform. It does not prove the message reached the person or that the person completed authentication. Reconcile message status events with your own verification result without storing the passcode in analytics or conversation notes.

If a customer asks for help, route the conversation into a controlled team inbox without exposing the code. Agents should verify identity through the approved support process and should never ask the customer to read a one time password aloud.

Avoid common rejection causes

• The selected category does not match the message purpose.
• The text contains marketing language or an unrelated call to action.
• The submitted language does not match the actual message.
• Variables or examples do not show a realistic authentication use case.
• One tap uses the wrong Android package or signing hash.
• The App Review recording does not show the requested permission in the submitted app.
• The recording exposes secrets or uses customer information.
• The production workflow treats API acceptance as completed verification.

When a review fails, read the returned reason, change the smallest relevant item and document the new revision. Avoid repeatedly resubmitting an unchanged template.

Keep access and evidence controlled

Give template management and message sending only to the roles that need them. Separate test and production assets, rotate credentials through the approved process and keep an audit trail for template changes. DripTell's security and access controls can support role separation and workspace boundaries, but Meta permission approval and authentication security remain the responsibility of the app owner.

The practical rule is simple. Prove the template is allowed, prove the app is allowed to perform its actions and prove the customer completed verification. These are three different facts and should be measured separately.

Frequently asked questions

Do all authentication templates need App Review?

Every template needs template approval. App Review depends on the Meta app's permission and access model. Check the permissions requested in the developer dashboard and whether the app acts only on its own assets or for customer businesses.

Does an approved template mean OTP delivery is working?

No. Approval allows the template to be used. You still need to test delivery status, expiry, single use, fallback and the final verification result.

Can a one tap template work without an Android package and signing hash?

Meta's official one tap example requires both values. If they do not match the installed release app, use the copy code fallback and correct the production configuration.