WhatsApp Direct Send deja de poner solo el botón «copiar código» en los OTP: ahora hay que declararlo

Si mandas códigos de verificación por WhatsApp con Direct Send y dependías de que Meta "adivinara" el código dentro de un texto para ponerle el botón de copiar, eso se acabó. El 27 de octubre de 2026, Meta registró en el changelog de la WhatsApp Business Platform que retiró, de forma predeterminada, la inferencia automática del OTP y la generación del botón copy code en los mensajes de autenticación de texto enviados con Direct Send. La alternativa oficial es explícita: mandar un mensaje interactivo de autenticación y poner tú el código en el campo otp.code. Para quien opera bots de login, verificación de cuenta o confirmación de pagos, la diferencia se nota en la experiencia del usuario y en cuánto tarda en escribir el código.

Qué cambió exactamente

Direct Send es la modalidad de la Cloud API que permite mandar mensajes iniciados por el negocio, de utilidad o de autenticación, sin crear plantillas antes. Le agregas un campo category a la llamada normal de /<PHONE_NUMBER_ID>/messages, y Meta genera y empareja las plantillas por detrás.

La entrada del changelog del 27 de octubre es corta. Meta dice que "deprecó la inferencia automática del OTP y la generación del botón copy code" para los mensajes de autenticación de texto de Direct Send, "por defecto". La página de tipos de mensaje soportados, actualizada ese mismo día, lo deja más claro: Direct Send ya no infiere un OTP a partir de un mensaje de texto ni agrega solo un botón de copiar código. Si quieres el botón, tienes que usar el mensaje interactivo de autenticación y declarar el código.

En la práctica:

Un mensaje con "type": "text" y "category": "authentication" se sigue enviando, pero llega como texto plano, sin botón para copiar.
Si quieres el botón, el mensaje tiene que ser "type": "interactive" con un botón de tipo otp.

Diagrama: antes Meta detectaba el OTP en un mensaje de texto y agregaba el botón Copy Code; desde el 27 de octubre de 2026 el texto llega sin botón y el botón solo aparece con un mensaje interactivo que declara el código en otp.code

La alternativa: mensajes interactivos de autenticación

El soporte para estos mensajes llegó dos semanas antes. El 14 de octubre de 2026, Meta agregó OTP interactivo a los mensajes de autenticación de Direct Send, para enviar la experiencia de copy code "sin crear antes una plantilla de autenticación". Direct Send crea y usa la plantilla por ti.

Los requisitos, según la documentación:

Campo	Regla
`category` (nivel superior)	`authentication`
`type` / `interactive.type`	`interactive` / `button`
Botones	Exactamente uno, de tipo `otp`
`otp.code`	De 4 a 10 caracteres ASCII alfanuméricos; el mismo código tiene que aparecer como valor independiente en `interactive.body.text`
`otp.otp_type`	Obligatorio, solo acepta `copy_code`
`otp.text`	Opcional, etiqueta del botón; por defecto `Copy Code`, máximo 25 caracteres, sin emojis, URLs, saltos de línea ni variables
`otp.code_expiration_minutes`	Opcional, de 1 a 90 minutos; por defecto 10
Destinatario	`to` con número de teléfono; los mensajes de autenticación no aceptan business-scoped user IDs

El cuerpo de una petición mínima queda así (adaptado del ejemplo oficial):

{
  "messaging_product": "whatsapp",
  "recipient_type": "individual",
  "to": "<NUMERO_DEL_USUARIO>",
  "type": "interactive",
  "category": "authentication",
  "interactive": {
    "type": "button",
    "body": { "text": "Tu código de verificación es 482913." },
    "action": {
      "buttons": [
        {
          "type": "otp",
          "otp": {
            "code": "482913",
            "otp_type": "copy_code",
            "text": "Copiar código",
            "code_expiration_minutes": 10
          }
        }
      ]
    }
  }
}

No lo probé; esto sale de la documentación oficial de Meta. Hay dos detalles que es fácil pasar por alto: el código tiene que estar literalmente en el texto del cuerpo, como valor suelto, y solo se permite un botón. No puedes mezclar el botón OTP con botones de respuesta o de URL en el mismo mensaje.

A quién le pega

A menos gente de la que parece, pero a esa gente le pega directo.

Direct Send para autenticación sigue en alfa y con acceso restringido. La página principal de Direct Send lo describe como alfa y pide llenar un formulario de interés. La referencia del campo category dice que para usar authentication hay que pedirle acceso a tu partner o client manager. El changelog del 31 de julio, cuando Direct Send de utilidad pasó a disponibilidad general, decía que la autenticación "sigue en beta". Las etiquetas no cuadran entre páginas, pero la conclusión es la misma: no está abierto para todos.

O sea, este cambio afecta sobre todo a:

Negocios y BSPs que ya entraron al programa de autenticación con Direct Send y mandan OTPs como texto simple.
Integraciones que daban por hecho que el botón aparecía solo porque el texto traía algo que parecía un código.

Si mandas tus OTPs con plantillas de autenticación clásicas (las que creas con la Message Templates API, con botón otp de tipo copy_code), este cambio no las toca. La entrada del changelog solo habla de Direct Send.

Qué hacer si ya lo usas

Busca en tu código los envíos con "category": "authentication" y "type": "text". Esos son los que perdieron el botón.
Migra al formato interactivo: mueve el texto a interactive.body.text, pon el código en otp.code y revisa que aparezca igual en el cuerpo.
Valida el código antes de enviarlo: de 4 a 10 caracteres alfanuméricos ASCII. Si tu generador mete símbolos (las plantillas clásicas aceptan cosas como J$FpnYnP en su ejemplo), ajústalo para Direct Send.
Revisa el destinatario: si migraste a business-scoped user IDs en otros flujos, la autenticación sigue exigiendo número de teléfono en to.
Ajusta la caducidad: si no mandas code_expiration_minutes, quedan 10 minutos por defecto.

Ten en cuenta también lo que Meta agregó el 15 de octubre: los mensajes de Direct Send están sujetos al pacing del portafolio. Un mensaje frenado puede retenerse o descartarse, y el descarte solo te llega por el webhook de estado (failed, error 135000). En un OTP, un mensaje retenido es casi igual de inútil que uno descartado, así que vale la pena vigilar ese webhook.

Mi lectura

Mi lectura es que Meta está cambiando magia por contrato. La inferencia automática era cómoda, pero ambigua: dejaba que un sistema decidiera qué parte de tu texto era "el código". Si se equivocaba, el usuario copiaba lo que no era. Con otp.code, el desarrollador declara el dato y Meta solo comprueba que coincida con el cuerpo. Es menos mágico y más predecible, que es lo que quieres en un flujo de login.

También me parece revelador el orden: primero, el 14 de octubre, sale el formato interactivo, y trece días después se apaga el comportamiento implícito. Es la secuencia clásica de "ya tienes alternativa, ahora úsala". Lo que no dice la documentación es si el "por defecto" implica que alguna cuenta puede reactivar la inferencia. No encontré ninguna opción documentada para eso, así que yo no contaría con ella.