WhatsApp OTP Templates: The PendingIntent Deadline and What Replaces It

What is being deprecated on 15 October 2026, and what is not?

Search "whatsapp otp android sdk deprecation" and most of what comes back reads as if one-tap autofill for WhatsApp OTP codes is going away. It is not. What Meta's own documentation says is narrower and more specific: Meta is deprecating the PendingIntent-based handshake method, not one-tap autofill itself. The button stays; the mechanism an Android app uses to prove its identity before that button appears is what changes.

Meta's page on one-tap autofill templates states it plainly: "Deprecation extension announcement: We will extend the migration deadline until October 15, 2026. On this date, the PendingIntent-based handshake method for authentication templates will be deprecated. If you are currently using PendingIntent to initiate handshakes or verify app identity, the OTP Android SDK is the preferred way to migrate." (Meta - One-tap autofill authentication templates)

That single sentence carries three separate facts worth pulling apart. First, the thing being retired is a handshake method - the Android intent and PendingIntent object your app uses to signal it is expecting a code - not the authentication template category, not the one-tap button as a concept, and not WhatsApp's willingness to deliver OTP codes. Second, the replacement is named: the OTP Android SDK. Third, and this is the part almost nobody leads with, the date in that sentence is an extended one - the word "extend" only makes sense if a deadline existed before it.

Checked against Meta's documentation on 4 September 2026.

The diagram below lays out both paths side by side, plus the one every integration eventually discovers whether it plans for it or not: what happens on a device that was never part of the handshake conversation at all.

• What is being deprecated on 15 October 2026, and what is not?
• Why did Meta extend this deadline once already?
• What is the OTP Android SDK, and what does migrating to it involve?
• What does a user on an iPhone see instead of a one-tap button?
• Which fields must match exactly for autofill to work at all?
• How long can an authentication code stay valid?
• Are authentication templates available to businesses in India?
• What does the deprecated CATEGORY_NOT_AVAILABLE reason tell you about regions?
• What text can you actually put in an authentication template?
• What should a team ship before mid-October, and what can wait?

Why did Meta extend this deadline once already?

Here is where the honest answer is less satisfying than a clean timeline would be. Meta's own page uses the word "extend" - not "announce" or "set" - which only makes grammatical sense if a migration deadline for this handshake existed before 15 October 2026. That wording is Meta's own confirmation that this is not the first deadline, but the page checked in this session does not publish what the earlier date was, and no independent source turned up a citable original date either. Rather than guess at a number that would look precise and might be wrong, this section states only what the primary source actually supports: an extension happened, and the current, operative date is 15 October 2026.

What that pattern is still useful for is planning. A deadline that has already moved once is a deadline worth treating as real rather than a moving target - Meta's WhatsApp Business Platform pricing page, for comparison, gives quarterly rate changes a minimum of one month's notice and a genuine pricing-model change six months' notice (Meta - Pricing on the WhatsApp Business Platform), which is the same posture of "we will tell you before we act, but we will act." Teams that treat an extended deadline as cancelled tend to be the ones still shipping PendingIntent code in the week it stops being honoured.

Checked against Meta's documentation on 4 September 2026.

What is the OTP Android SDK, and what does migrating to it involve?

The SDK is a small Android library, not a new integration surface. Meta's instructions are two Gradle lines: implementation 'com.whatsapp.otp:whatsapp-otp-android-sdk:1.0.0' in dependencies, and mavenCentral() added to repositories (Meta - One-tap autofill authentication templates).

Once it is on the classpath, two objects do the work that a hand-rolled PendingIntent implementation used to do manually:

• WhatsAppOtpHandler.sendOtpIntentToWhatsApp(context) starts the handshake and returns a UUID, which the app stores to check against later.
• WhatsAppOtpIncomingIntentHandler.processOtpCode(), called from the activity that receives the code, validates that returned handshake ID and hands back the verified code (or an error) through a callback.

The SDK does not add a capability that manual PendingIntent code lacked; it replaces a page of intent-flag and broadcast-receiver bookkeeping with two method calls, and it standardises the error surface: Meta documents three handshake-ID error codes under the SDK - HANDSHAKE_ID_MISSING, HANDSHAKE_ID_INVALID_FORMAT, and HANDSHAKE_ID_MISMATCH - that a manual implementation would otherwise have to detect and label itself.

Migrating means three concrete changes to an Android codebase: swap the handshake-initiation call for sendOtpIntentToWhatsApp(), swap the receiving activity's manual intent-extraction for the WhatsAppOtpIncomingIntentHandler, and stop setting FLAG_IMMUTABLE/FLAG_MUTABLE on a PendingIntent object that no longer exists in your code at all. Nothing about the template itself - its name, its approval, its category - needs to change for this migration; the work is entirely inside the Android app.

Checked against Meta's documentation on 4 September 2026.

What does a user on an iPhone see instead of a one-tap button?

Until recently, the honest answer was: a copy-code button, full stop. That remains true today for older iOS versions. Meta's page on one-tap autofill is direct about the limitation: "One-tap autofill buttons are only supported on Android. If you send an authentication template to a WhatsApp user who is using a non-Android device, the WhatsApp client will display a copy code button instead." (Meta - One-tap autofill authentication templates)

What has changed is what happens after that copy-code button appears, on the newest iPhones. Meta's authentication-templates overview states: "Effective June 15, 2026, on iOS 26 and later, Keyboard suggestions will provide native OTP autofill from the push notification with no integration required." (Meta - Authentication templates) The same page adds that this is "enabled by default for all authentication templates" - not a new button type a business has to build or request, but a change in what the operating system's own keyboard does when it detects an OTP-shaped push notification.

No integration required is the operative phrase - a business ships nothing to get this, and cannot opt out of it either, since it is a platform-level iOS behaviour rather than a WhatsApp template feature. On iOS versions before 26, or on any Android device that fails the eligibility check described below, the copy-code button is still what a user gets, and still what a support ticket about "the autofill button isn't showing" usually turns out to be.

Checked against Meta's documentation on 4 September 2026.

Which fields must match exactly for autofill to work at all?

This is the part that turns into a silent production bug more often than any other piece of an OTP integration, because a failed check produces no error message anywhere a developer is likely to be looking - the message still sends, still delivers, and just quietly shows the wrong button. Meta's documentation lists the checks WhatsApp performs on every authentication template message before deciding whether to show one-tap or fall back:

• The handshake was initiated no more than 10 minutes ago, or no more than the template's code_expiration_minutes value if one is set.
• "The package name in the message... matches the package name set on the intent. The match is determined through the getCreatorPackage method called in the PendingIntent object provided by your application."
• None of the other apps listed in the template's supported_apps array initiated a handshake in that same window.
• "The app signing key hash in the message... matches your installed app's signing key hash."
• The message includes the one-tap autofill button text, and the app has an activity defined to receive the code.

(All quotations: Meta - One-tap autofill authentication templates)

Two of those fields also carry hard formatting rules at template-creation time. The package name "must have at least two segments (one or more dots), and each segment must start with a letter," using only alphanumeric characters or underscores, up to 224 characters. The signature hash "must be exactly 11 characters," alphanumeric plus +, /, or = only. Get either wrong at creation, or let either drift after a rebuild, and the failure mode is not a rejected template - it is a template that sends normally and silently shows a copy-code button instead of autofill, which is why this is worth checking against the actual approved template rather than assumed from the build config.

Checked against Meta's documentation on 4 September 2026.

How long can an authentication code stay valid?

Meta's Message Templates API exposes this as a single optional field, code_expiration_minutes, on the template's footer component. The documented range is narrow and explicit: "Minimum 1, maximum 90." Leave it unset and the behaviour is not "no expiry" - Meta's page is specific that "the code expiration warning will not be displayed in the delivered message. In addition, the button will be disabled 10 minutes from when the message was sent." (Meta - One-tap autofill authentication templates)

That default matters for more than cosmetics: the same 10-minute figure (or the custom value, if one is set) is also the window the eligibility check uses to decide whether a handshake is still fresh enough to trust, so raising or lowering code_expiration_minutes changes both what the user reads in the message footer and how long a stale handshake is allowed to still authenticate a code. A team that sets a 60-minute expiry for a slow onboarding flow but never revisits the number after launch is, deliberately or not, holding the autofill handshake window open for that same hour.

The value is also visible before a template goes live, through the Message Template Previews API, which can render the exact footer text - "This code expires in 10 minutes," for instance - for a given code_expiration_minutes value and language, before anything is sent to a real user.

Checked against Meta's documentation on 4 September 2026.

Are authentication templates available to businesses in India?

This question surfaces constantly around WhatsApp OTP, and it deserves a careful answer rather than a confident one, because the confident answers found while researching this piece did not hold up. Several vendor pages, when searched, implied or asserted that Meta restricts authentication templates in India; none of the specific pages that appeared to make that claim, once actually opened, contained that text at all.

So the method here is stated plainly: both of Meta's authentication-template documentation pages - the overview and the one-tap autofill page - were read in full on 4 September 2026, searching specifically for the words "India," "country," "not available," and "not supported in." None of those four strings appears on either page. That is a measured absence, not proof that no restriction has ever existed anywhere in Meta's systems, but it is what the primary documentation actually contains today.

Separately, Meta's general pricing documentation confirms India is an actively served, separately billed market for the WhatsApp Business Platform: "Billing localization launched on January 1, 2026 for partners and directly-integrated clients whose Sold-To country is India in Billing Hub (eligible customers)," with its own INR rate cards published alongside markets like the US, UK, and UAE (Meta - Pricing on the WhatsApp Business Platform). None of that is authentication-specific proof, but it is consistent with India being an ordinary, fully-priced market rather than an excluded one. Actual figures belong on WhatsApp Business API pricing in India rather than in a numeral here, since Meta revises rate cards quarterly. Businesses that also fall back to SMS for OTP delivery in India carry a separate compliance burden entirely - mandatory DLT registration - which has nothing to do with WhatsApp templates and is easy to conflate with this question. The one place a historical regional restriction on authentication templates does turn up in Meta's own systems, and what it does and does not tell you, is the next section.

Checked against Meta's documentation on 4 September 2026.

What does the deprecated CATEGORY_NOT_AVAILABLE reason tell you about regions?

Meta's message_template_status_update webhook reference publishes the full list of values its reason field can carry when a template is rejected. One entry, read directly from that reference on 4 September 2026, is this: "CATEGORY_NOT_AVAILABLE — (Deprecated) Indicates an authentication templates for an unsupported region." (Meta - message_template_status_update webhook reference)

That single line is worth reading slowly, because it proves two different things at once. First, it confirms that Meta's systems have, at some point, rejected authentication templates specifically because of the region they were created for - the enum value would not exist otherwise. Second, and this is the part easy to miss, it is marked (Deprecated) in Meta's own reference. The reason code that once told a developer "your region can't have this" is no longer active - Meta's documentation does not say when it stopped firing, which regions it used to fire for, or whether every affected region was subsequently unblocked.

What that means practically: a business that gets template rejections today should not expect to see CATEGORY_NOT_AVAILABLE in the payload, because Meta's own reference marks it retired. If a rejection webhook does still carry it, that is itself worth reporting to Meta as unexpected, given the reference's own status label. Beyond confirming that regional gating of authentication templates has existed as a mechanism, this entry does not name India, and nothing else read in this session does either - which is why the previous section states its finding as an absence, not a guarantee. It sits in the same enum as the ordinary rejection reasons behind an account losing sending ability, a different failure mode covered in what a restricted WhatsApp account actually means.

Checked against Meta's documentation on 4 September 2026.

What text can you actually put in an authentication template?

Less than most people expect, and that is by design rather than an oversight. Meta's authentication-templates overview describes the body as "Fixed, non-customizable preset text: <VERIFICATION_CODE> is your verification code," with exactly two optional additions on top of it: a security disclaimer ("For your security, do not share this code") and an expiration warning ("This code expires in <NUM_MINUTES> minutes") (Meta - Authentication templates).

The body text cannot be reworded at all - not the greeting, not the brand name, not the sentence structure - which is the opposite of every other template category, where the body is the whole point of customisation. What can be changed is narrower still: the copy-code and autofill button labels, each up to 25 characters, defaulting to a localised preset like "Copy Code" or "Autofill" if left blank. The same page states flatly that "URLs, media, and emojis are not supported" anywhere in an authentication template.

Checking what a live template actually looks like once approved is easier in the templates screen than in the API response, since the table view shows name, category, language and approval status together in one place.

That narrowness is also the reason authentication templates rarely get caught in the kind of category dispute covered in what happens when a template is recategorised from utility to marketing - there is no marketing language to accidentally include when the body text is not writable in the first place.

Checked against Meta's documentation on 4 September 2026.

What should a team ship before mid-October, and what can wait?

Given everything above, the priority list separates cleanly into one dated item and several that are not time-boxed at all.

Dated, and worth doing before 15 October 2026: any Android code that still initiates a handshake through a manually built PendingIntent, or verifies app identity through getCreatorPackage calls written by hand, needs to move to the OTP Android SDK's sendOtpIntentToWhatsApp() and WhatsAppOtpIncomingIntentHandler. This is the one change with an actual, Meta-stated cutoff. Confirm which handshake method your Android build currently uses - not which one the WabaCRM template was created with, since the template and the client-side handshake are separate concerns entirely.

Not dated, and worth checking regardless: whether your app's package_name and signature_hash on file in the template's supported_apps array still match your current signing configuration, particularly if the app has moved to Play App Signing or a new release keystore since the template was created. Whether code_expiration_minutes is set to a value that matches how long your product actually expects a code to remain valid, rather than the unstated 10-minute default. And whether the account is watching for a template moving into rejected or archived status, since an authentication template that gets flagged behaves the same as any other category once Meta's review process is involved.

None of this requires a new template, a new category, or a conversation with Meta - it is entirely a client-side migration inside an Android codebase, which is also why it is the kind of deadline that is easy for a WhatsApp integration team to miss: nothing in the templates screen or the WhatsApp Manager UI flags it, because from the template's side, nothing about it changed at all.

Checked against Meta's documentation on 4 September 2026.

Every Meta quotation on this page was read from Meta's own documentation on 4 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.