# Plantillas de WhatsApp — cuerpos listos para Postman

Generados desde [`../plantillas.json`](../plantillas.json) el 2026-09-04.

Cada archivo es **el cuerpo exacto del POST**: se copia completo y se pega en
Postman → *Body* → *raw* → *JSON*. No hay que quitarle ni agregarle nada.

## El request

```
POST https://graph.facebook.com/v26.0/{WABA_ID}/message_templates
Authorization: Bearer {TOKEN}
Content-Type: application/json
```

WABA de Pádel: `1581728670124474`

Respuesta esperada:

```json
{ "id": "...", "status": "PENDING", "category": "UTILITY" }
```

## Por qué estos archivos no son el JSON original

Del export se quitaron los campos que **asigna Meta** y que hacen que Graph
rechace la creación completa si viajan en el POST:

`id` · `status` · `sub_category` · `disable_ios_autofill` ·
`is_primary_device_delivery_only`

Lo que sí se conservó, y es lo que más se pierde al copiar a mano: el bloque
**`example`**. Es obligatorio en toda plantilla con `{{n}}` — sin él la
creación falla con un error que no dice claramente que ese es el problema.

## Avance

| # | Plantilla | Categoría | Formato | Variables | Creada |
|---|---|---|---|---|---|
| 01 | `pad_registro_padel` | UTILITY | POSITIONAL | 2 | ☐ |
| 02 | `pad_cancelacion_partida_privada` | UTILITY | POSITIONAL | 3 | ☐ |
| 03 | `pad_partida_confirmada` | UTILITY | POSITIONAL | 3 | ☐ |
| 04 | `pad_evento` | **MARKETING** | POSITIONAL | 1 | ☐ |
| 05 | `pad_aviso` | UTILITY | POSITIONAL | 1 | ☐ |
| 06 | `pad_nueva_partida_abierta` | **MARKETING** | POSITIONAL | 3 | ☐ |
| 07 | `pad_cambio_contrasenia` | UTILITY | POSITIONAL | 1 | ☐ |
| 08 | `pad_confirmacion` | UTILITY | POSITIONAL | 3 | ☐ |
| 09 | `pad_invitacion_privada` | **MARKETING** | POSITIONAL | 3 | ☐ |
| 10 | `pad_invitacion_grupo` | UTILITY | POSITIONAL | 2 | ☐ |
| 11 | `pad_prueba` | UTILITY | **NAMED** | 2 · nombre_jugador, nombre_grupo | ☐ |
| 12 | `pad_codigo_cam` | UTILITY | POSITIONAL | 1 | ☐ |

Todas son **POSITIONAL** (`{{1}}`, `{{2}}`…) salvo la 11, que quedó con
variables por nombre. La 08, 09 y 10 se convirtieron de NAMED a POSITIONAL el
2026-09-04: el índice sigue el **orden de aparición en el texto**.

El formato no cambia nada al **crearlas**, pero sí el cuerpo al **enviarlas**:
en POSITIONAL los parámetros van sin `parameter_name` y el orden manda. Ver
[`_ENVIAR-ejemplo.md`](_ENVIAR-ejemplo.md).

## Las tres MARKETING

`pad_evento`, `pad_nueva_partida_abierta` y `pad_invitacion_privada` van como
`MARKETING`, y eso no es un detalle administrativo: revisión más estricta, costo
por mensaje distinto, y **requieren opt-in** del socio.

Si en realidad son avisos operativos hacia socios que ya tienen relación con el
club, vale la pena revisar si califican como `UTILITY`. Pero no se cambia solo
por abaratar: si Meta considera que el contenido es promocional y se envió como
utility, rechaza la plantilla o sanciona la cuenta.

## Verificar cómo van

```
GET https://graph.facebook.com/v26.0/1581728670124474/message_templates?fields=name,language,status,rejected_reason
```

Las `UTILITY` suelen aprobarse en minutos. Si alguna sale `REJECTED`, el
`rejected_reason` dice por qué.

## Si prefieres no hacerlo una por una

Hay dos alternativas que hacen las 11 de golpe —un script de PHP y un script de
Postman con `pm.sendRequest()`—; ambas leen del WABA de origen, saltan las que
ya existen y espacian las llamadas para no topar el rate limit.