Novedades de la API

Filtro de conversaciones pendientes de respuesta

La bandeja de Contactos ahora incluye el filtro rápido Sin respuesta. Una conversación aparece allí cuando el cliente escribió y todavía no recibió una respuesta posterior de una persona del equipo. Las respuestas del asistente y los mensajes automáticos no retiran el chat del filtro.

Abrir o leer el chat no cambia esta clasificación. Las notas internas, los eventos del sistema y los mensajes salientes cuya entrega falló tampoco se consideran respuestas.

La API pública de contactos acepta el parámetro opcional unanswered=true en el listado y en los conteos de bandeja.

Cada workspace tiene un límite de tareas por minuto, y lo que pasa del límite espera su turno

Desde esta versión, cada workspace tiene un límite de tareas por minuto según su plan. Una tarea es cada vez que corre un flujo: una automatización, una difusión, un mensaje que entra por un canal, un salto a otro flujo o una prueba manual. Las Funciones IA no cuentan: el Met que las llama espera la respuesta y no puede hacer fila.

Nada se pierde al pasarse. Lo que supera el límite espera su turno del minuto siguiente y arranca solo. Si una tarea espera más de 10 minutos, o la fila del workspace ya tiene 10 minutos de capacidad, se rechaza con un mensaje que dice qué hacer. Al primer freno de cada hora, los admins del workspace reciben un aviso.

Si tu operación necesita más, el complemento «20 tareas extra por minuto» (US$15 al mes, acumulable) sube el límite.

Cómo consultarlo

GET /billing/limits trae el recurso nuevo automation_tasks_per_minute:

• limit es el límite que se aplica hoy (plan más complementos).
• used es el minuto con más tareas de las últimas 24 horas, para que veas qué tan cerca llegas en tus picos.
• period es minute y resets_at va en null.
• enforcement es queue, un valor nuevo: lo que pasa del límite hace fila en vez de rechazarse o de solo avisar.

Si tu integración valida period o enforcement contra una lista cerrada, agrega minute y queue.

Reemplaza colecciones con claves compuestas y una vista previa vinculante

POST /collections/{collectionId}/items/import admite ahora keyFields en el modo replace_active. Puedes combinar hasta cuatro campos para identificar una fila, por ejemplo identificacion_del_cliente + codigo cuando un mismo cliente tiene varios productos. keyField sigue disponible y conserva compatibilidad con las integraciones existentes.

La vista previa devuelve preview_token. Debes reenviarlo como previewToken al confirmar. Si otro usuario modifica los registros vigentes después de la vista previa, la confirmación responde con conflicto y no escribe cambios. Esto evita aplicar un cálculo desactualizado sobre una colección que ya cambió.

Cuando el reemplazo archivaría 30 % o más de los registros vigentes, también se requiere allowHighArchive: true. La operación continúa siendo transaccional: los ausentes se archivan sin borrado físico, los códigos de registros existentes se conservan y cualquier error revierte el reemplazo completo.

Cambia los eventos de un webhook sin cambiar su secreto

Hasta hoy, para sumar un evento a un endpoint había que borrarlo y crear otro, y con eso cambiaba el secreto de firma: tocaba redesplegar la verificación.

Ahora PATCH /webhook-endpoints/{id} cambia los eventos, la URL o la descripción de un endpoint, y el secreto sigue siendo el mismo. enabled_events reemplaza la lista completa: para sumar un evento, manda la actual más el nuevo.

const [ep] = await met.webhooks.subscriptions.list();
await met.webhooks.subscriptions.update(ep.id, {
  enabled_events: [...ep.enabled_events, 'contact.message.failed'],
});

El método update está en el SDK desde @meteor.ia/sdk 0.9.1, y en Python desde meteor-ia 0.3.0: met.webhooks.subscriptions.update(endpoint_id, enabled_events=[...]).

Manda al menos un campo. Cambiar la URL no reactiva un endpoint que se apagó por fallos seguidos.

Nuevo evento contact.message.failed, con el código de error de WhatsApp

Hasta hoy, un mensaje que no llegaba solo se veía consultando GET /contacts/{id}/messages contacto por contacto. Ahora sale el evento contact.message.failed (scope conversations:read) cuando un mensaje hacia un contacto queda sin entregar: porque el proveedor lo rechazó al enviarlo, o porque WhatsApp lo marcó como fallido después.

Trae los mismos campos que contact.message.sent, más:

{
  "type": "contact.message.failed",
  "data": {
    "contact_id": 4821,
    "message_id": 458112,
    "channel_type": "whatsapp",
    "message_type": "template",
    "origin": "api",
    "template_name": "recordatorio_pago",
    "error": { "code": 131026, "message": "Message undeliverable" }
  }
}

El código separa causas que piden cosas distintas:

• 131026: el número no puede recibir el mensaje. Revísalo antes de volver a enviar.
• 131049: Meta frenó las plantillas de marketing a esa persona. El número está bien; espacia los envíos.
• 132012, 131009, 132000: un parámetro no coincide con la plantilla. Corrige el envío.

Sale una sola vez por mensaje. El mismo dato queda en metadata.delivery_status y metadata.delivery_error de cada mensaje en GET /contacts/{id}/messages.

Cada mensaje dice quién lo originó, también cuando sale con tu API key

Hasta hoy, un mensaje que tu integración mandaba con su API key quedaba igual que uno escrito a mano desde la bandeja: role: operator y el sent_by_user_id del dueño de la key. No había forma de separarlos.

Ahora cada mensaje trae origin, en GET /contacts/{id}/messages, en la respuesta de los envíos y en el evento contact.message.sent:

Los mensajes nuevos quedan marcados al enviarse. Los anteriores se deducen de lo que ya estaba guardado, con una excepción: lo que tu integración envió por API antes del 25 de septiembre de 2026 aparece como panel, porque en ese momento el origen no se registraba.

sent_from sigue en contact.message.sent sin cambios, para no romper a quien ya lo usa. origin es la versión fina.

Cada workspace tiene un límite diario de peticiones, con cabeceras propias y un endpoint para consultarlo

Desde esta versión, cada workspace tiene un límite diario de peticiones que depende de su plan. Si tu integración hace mucho tráfico por día, léelo entero: hay un 429 nuevo y conviene que tu código lo reconozca.

Qué cuenta y cuánto trae cada plan

Cuenta toda petición autenticada con una API key, llegue por la API, el SDK, la CLI o el servidor MCP. En el MCP, cada POST /mcp es una petición. El límite es del workspace: se suman todas sus keys. El día es el día UTC, y el contador vuelve a cero a las 00:00 UTC.

Por ahora, pasar el 100 % solo avisa

Al llegar al 100 % del límite, tu workspace recibe un aviso (una vez por día) y la API sigue respondiendo. El freno llega al triple del límite: desde ahí, toda petición con key de ese workspace responde 429 hasta las 00:00 UTC.

{
  "error": {
    "type": "rate_limit_error",
    "code": "daily_request_limit_exceeded",
    "message": "Tu workspace superó el límite diario de peticiones."
  }
}

La respuesta trae Retry-After con los segundos que faltan para el reinicio, y pueden ser horas. No lo trates como el rate_limited de siempre: reintentar en unos segundos no lo resuelve. Si tu código reintenta todo 429 en un bucle, agrega una rama para daily_request_limit_exceeded. Desde @meteor.ia/sdk 0.9.0 y meteor-ia 0.3.0, los SDKs oficiales no lo reintentan: te entregan el error de una vez, con retryAfter (retry_after en Python) y isQuota en true.

Tres cabeceras nuevas en cada respuesta

Si corres trabajos por lotes, mira X-Daily-Remaining y frena antes de llegar al triple.

GET /billing/limits: todos los límites del plan en una llamada

Un endpoint nuevo, con el scope billing:read, que devuelve cada límite de tu plan con lo usado, lo incluido, lo que suman tus complementos y cómo se aplica:

{
  "key": "api_requests_daily",
  "period": "day",
  "used": 6880,
  "included": 10000,
  "extra": 0,
  "limit": 10000,
  "unlimited": false,
  "enforcement": "soft",
  "resets_at": "2026-09-26T00:00:00Z"
}

Además del límite diario de peticiones trae miembros, contactos, tareas al día, números de WhatsApp y cuentas de Meta, cada uno con los complementos que lo amplían.

Si te quedas corto: el complemento «Peticiones de API»

No hace falta cambiar de plan: +1.000 peticiones al día por US$15 al mes o +10.000 al día por US$90 al mes, en Facturación → Complementos. Se suma a lo que trae tu plan y aparece en X-Daily-Limit.

Lo que no cambia

El rate limit por minuto de cada key sigue igual: 300 por minuto por defecto, y 60 en los planes Developer y Tech Partner. Las cabeceras X-RateLimit-* y el 429 rate_limited funcionan como siempre.

El detalle completo está en la guía de límites y cuotas.

Tu asistente de IA ya construye en Met — Mets, flujos, colecciones y cualquier operación de la API

Hasta hoy, conectar Met a Claude, ChatGPT o Cursor servía para el día a día: contestar, buscar contactos, agendar, correr un Met. Ahora tu asistente también construye: crea y ajusta Mets, arma y publica flujos, programa automatizaciones y crea colecciones con sus campos. Y lo que no tiene una tool propia lo alcanza igual.

Tools nuevas por dominio. El catálogo del servidor MCP suma:

• Conversaciones y canales: listar y buscar conversaciones, notas, etiquetas, asignar a una persona o a un grupo, respuestas rápidas y plantillas de WhatsApp (para escribir fuera de la ventana de 24 h).
• Mets: crear y editar un Met, activar y vincular habilidades con sus credenciales, crear y vincular Funciones, y elegir qué tools tiene apagadas.
• Flujos y automatizaciones: los catálogos de nodos y disparadores, crear un flujo, editar su borrador, probar un nodo, publicar, duplicar e importar; crear, programar y ejecutar automatizaciones, y cancelar ejecuciones.
• Datos: crear colecciones, campos y vistas; estado y comentarios de los items; pasos de las tareas.
• Cuenta: uso del plan, saldo y consumo de Energía, integraciones y eventos.

La tabla completa está en Servidor MCP.

Cualquier operación de la API, con tres tools. met_search_operations, met_describe_operation y met_call_operation buscan una operación del contrato público, muestran sus parámetros y la llaman con tu mismo token. Exigen el scope de la operación y pasan por los mismos controles que la API. Quedan fuera las subidas y descargas de archivos, lo que devuelve un secreto (crear un webhook o rotar su secreto) y las operaciones de partners.

Confirmación en lo que no se deshace. Cada tool declara sus anotaciones MCP (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), que tu cliente usa para pedirte permiso. Borrar, publicar un flujo, ejecutar ya una automatización, instalar un snapshot o importar en lote exigen además confirm: true: sin él, la llamada falla sin tocar nada. Las tools que gastan Energía o tienen costo con Meta lo dicen en su descripción.

Respuestas que caben. Una respuesta de más de ~20.000 caracteres se recorta conservando JSON válido y llega como { "truncated": true, "note", "data" }; la nota dice cuántos elementos se muestran y cómo pedir el resto.

Reintentos sin duplicados. Toda escritura hecha desde el MCP lleva una Idempotency-Key automática: si tu cliente reintenta la misma llamada, no se crea dos veces.

Período vencido: lectura sí. Si tu workspace queda bloqueado por un período vencido, el asistente sigue consultando. Las escrituras responden 403 workspace_blocked.

Permisos nuevos al conectar. Al iniciar sesión, la lista de permisos ahora incluye los de construir (agents:write, flows:write, automations:write, collections:write, skills:manage, functions:write) y los de consultar la cuenta (billing:read, events:read). Si ya tenías Met conectado, desconéctalo y vuelve a conectarlo para aprobarlos. Con una API key, agrégale esos scopes.

Dos cambios de comportamiento.

• met_send_message respeta el piloto automático: si una persona del equipo está atendiendo la conversación (piloto apagado o en pausa, o el contacto pidió un humano), responde 409 autopilot_silenced y no envía nada. Antes el mensaje salía igual.
• met_update_item fusiona en vez de reemplazar: las claves de data que no mandas quedan como estaban. Si dependías de que se borraran, mándalas vacías.

¿No programas? Usa Met desde Claude en 3 pasos explica cómo conectarlo y qué pedirle.

Puedes evitar que una edición sobrescriba cambios más recientes

Al actualizar un campo de un ítem mediante PATCH /collections/{collectionId}/items/{itemId}/field, ahora puedes enviar expectedUpdatedAt con la versión que leíste. Meteor aplicará el cambio solo si el registro conserva esa versión.

Si otra operación lo modificó antes, la API responde con conflicto y mantiene intactos ambos cambios para que puedas volver a cargar el registro, compararlos y decidir cuál conservar.

El parámetro es opcional para mantener compatibles las integraciones actuales. Las interfaces operativas nuevas lo envían siempre que editan un registro existente.

Las notas de voz de tu equipo también llegan transcritas

Las notas de voz que graba tu equipo desde la bandeja, o el dueño desde WhatsApp Business en su celular, ahora se transcriben igual que las del contacto. Puedes medir y leer las dos mitades de la conversación sin escuchar un solo audio.

• En el webhook contact.message.sent, que ahora trae attachments con la misma forma que contact.message.received: url, type, name y, en las notas de voz, transcript.
• En GET /contacts/{id}/messages, en el mismo campo attachments[].transcript que ya usabas para los audios del contacto.

"attachments": [
  { "type": "audio", "url": "https://…/nota.webm", "name": "nota.webm", "transcript": "Ya te envié la guía, revisa tu correo" }
]

content no cambia. Las respuestas del Met no se transcriben: su texto ya viene en content.

Y GET /contacts documenta sus parámetros. limit, page, order, starting_after y filters ya funcionaban, pero no estaban en la referencia. Con filters puedes pedir, por ejemplo, los contactos que tuvieron mensajes desde una fecha:

GET /contacts?order=id&filters=[{"field":"$last_message_at","op":"after","value":"2026-09-24T00:00:00.000Z"}]

Una condición mal escrita se ignora sin dar error, así que revisa total antes de confiar en el resultado.

Consulta cada conversación por su línea

Si un mismo contacto escribe a varios números conectados, puedes consultar las líneas en las que tiene mensajes con GET /contacts/{contactId}/lines y filtrar GET /contacts/{contactId}/messages con line_id. Así mantienes una ficha de contacto sin mezclar las conversaciones de cada número.

Al enviar un mensaje también puedes indicar line_id para elegir explícitamente la línea emisora. Debe pertenecer al espacio de trabajo; una línea inválida produce un error en lugar de enviar desde otro número.

Lee lo que dicen las notas de voz, sin transcribirlas tú

Cuando un contacto manda una nota de voz, ya no recibes solo un "[Audio]": el adjunto trae transcript con el texto de lo que dijo. Puedes buscar en las conversaciones, clasificarlas o alimentar tus reportes sin pagar ni montar tu propia transcripción.

"attachments": [
  { "type": "audio", "url": "https://…/nota.ogg", "transcript": "Hola, necesito una guía para mañana" }
]

• En el webhook contact.message.received, cuando la transcripción estuvo lista en los primeros 30 segundos.
• En GET /contacts/{id}/messages, siempre que exista, también para las notas de voz que ya tenías: no hace falta volver a pedirlas.

content sigue diciendo "[Audio]", así que tu integración actual no cambia.

Y una corrección en la guía de webhooks: decía que los reintentos llegaban hasta 24 horas. Son 6 intentos en unas 8,6 horas (1 min, 5 min, 30 min, 2 h y 6 h). La guía ahora también explica cómo evitar duplicados con el id del evento y por qué conviene ordenar por created.