Novedades de la API

Un teléfono tiene una sola ficha por espacio de trabajo

line_id ya no divide la identidad de un contacto. Un mismo teléfono tiene una sola ficha dentro del espacio de trabajo, sin importar por cuál línea de WhatsApp haya entrado o se le haya escrito.

Esto corrige lo que anunciamos el 14 de septiembre. Allí decíamos que POST /contacts/import usaba teléfono + línea como identidad y que el mismo número podía existir en dos líneas por separado. Ya no es así.

line_id sigue aceptándose y sigue validándose contra las líneas del espacio de trabajo —una línea inexistente o de otro espacio se rechaza igual que antes—, pero ahora se conserva como metadato de origen y emisión.

Qué cambia en la práctica: si importas el mismo teléfono por dos líneas distintas, antes obtenías dos contactos y ahora actualizas uno solo, según on_existing. Si tu integración contaba con dos fichas separadas para el mismo número, ese supuesto ya no se cumple.

Ninguna operación cambió de nombre, de ruta ni de forma: la corrección es de comportamiento y de la documentación que lo describía.

Duplicar un flujo acepta el nombre de la copia

POST /workspaces/{workspaceId}/flows/{id}/duplicate acepta ahora un cuerpo opcional con name, el nombre que llevará la copia.

Sin name el comportamiento no cambia: la copia se llama como el original más «(copia)». Las integraciones que ya llamaban al endpoint sin cuerpo siguen funcionando igual.

La copia sigue naciendo como draft, sin slug y sin disparadores: no ejecuta nada hasta que se publique. Copia el lienzo borrador (draft_definition), no la versión publicada.

Los contactos importados pueden conservar su línea de WhatsApp

POST /contacts/import acepta ahora line_id en cada contacto. El valor es el phone_number_id de una línea de WhatsApp conectada al mismo espacio de trabajo.

Cuando se envía, Meteor guarda el contacto en esa línea y usa teléfono + línea como identidad. Así, un mismo teléfono puede existir en dos líneas sin mezclar las conversaciones; si vuelve a importarse en la misma línea, se actualiza el contacto existente según on_existing.

Una línea inexistente o perteneciente a otro espacio de trabajo se rechaza para evitar que una importación asocie contactos al canal equivocado.

Un tope de gasto por conversación, consultable y reiniciable

Cada espacio de trabajo puede fijar un monto máximo de consumo por conversación. Al superarlo, el Met deja de responder en ese chat: el contacto no recibe ningún mensaje, la conversación queda marcada para atención humana y en el hilo aparece un aviso visible sólo para el equipo, con lo gastado y el tope que se alcanzó. El tope viene desactivado y se enciende desde Ajustes → Conversaciones.

El tope se revisa antes de cada turno, no durante, así que una conversación cierra un poco por encima del monto fijado. Es deliberado: cortar a mitad de una respuesta dejaría al contacto con media frase.

Dos operaciones nuevas acompañan el cambio. GET /contacts/{contactId}/budget devuelve el estado del tope para esa conversación: si está activo, el monto configurado, lo consumido hasta ahora, cuántas respuestas lo componen, desde cuándo se cuenta y si el Met ya se detuvo. POST /contacts/{contactId}/budget/reset vuelve el contador a cero y permite que el Met retome la conversación; es la única forma de reanudarla antes de que el contador se reinicie solo.

Ese reinicio automático ocurre al cerrar la conversación y también tras veinticuatro horas sin mensajes. Sin él, un contacto que escribe con regularidad alcanzaría el tope una vez y quedaría sin respuesta indefinidamente.

Ambas operaciones requieren los mismos permisos que gobiernan el piloto automático de un contacto, de modo que quien atiende el chat pueda reanudarlo sin depender de un administrador.

Actualización controlada de campos de contacto desde webhooks

Los mapeos de un webhook ahora aceptan on_existing: "overwrite" para actualizar un campo de contacto que ya contiene información. Si omites esta opción, el comportamiento no cambia: Meteor conserva el valor existente y solo completa campos vacíos. Las claves de identidad y enrutamiento del contacto no se pueden sobrescribir mediante esta opción.

Las colecciones pueden reemplazarse sin mezclar versiones anteriores

La importación de elementos de cualquier colección de usuario admite ahora el modo opcional replace_active. Las colecciones globales, internas y protegidas quedan excluidas para evitar cambios accidentales en datos del sistema. Este modo valida primero el archivo completo y, en una sola transacción, conserva como vigentes únicamente los registros incluidos en la nueva versión.

Antes de aplicar el reemplazo se puede ejecutar una vista previa con dryRun. La respuesta informa cuántos registros se crearán, actualizarán, reactivarán o archivarán, además del total vigente esperado. Cada ejecución exige una revisión identificable, una clave de identidad elegida por el usuario y una confirmación explícita con el nombre de la colección. La ejecución queda disponible para consulta posterior.

El comportamiento anterior de actualización por clave sigue disponible como modo predeterminado, por lo que las integraciones existentes no cambian.

La lectura de elementos también admite ahora el parámetro explícito status=active. Así una interfaz o integración puede mostrar únicamente la versión vigente después del reemplazo, mientras los registros archivados se conservan para consulta histórica sin quedar mezclados en el listado operativo.

Las conversiones web ya conservan el clic de Google Ads

POST /conversions/web acepta ahora gclid, gbraid y wbraid. Estos campos opcionales permiten que un sitio entregue a Google Ads el identificador del clic que originó una compra, cita o lead, usando el mismo event_id que evita contar dos veces una conversión.

Los tres identificadores se transmiten sin hash, como exige Google Data Manager. Los datos personales opcionales (email y phone) mantienen su tratamiento anterior: el backend los normaliza y cifra con SHA-256 antes de enviarlos.

El cambio es compatible con clientes existentes. Ningún campo nuevo es obligatorio y la ruta, el permiso conversions:write y la forma de respuesta no cambian.

Los flujos ya mandan archivos

El catálogo de nodos (GET /node-registry) incorpora channel.send_media: envía imágenes, videos, audios o documentos al contacto por su canal. Hasta hoy un flujo solo podía mandar texto, plantillas o mensajes interactivos, y la única forma de mandar un video era un nodo http.request apuntando a POST /contacts/{contactId}/messages con una API key.

Ese rodeo tenía un costo que no se veía: el backend leía esa llamada como «una persona escribió en la bandeja», así que los mensajes del bot quedaban firmados con el nombre del dueño de la key y cada envío pausaba el piloto automático, tragándose las respuestas que el contacto mandaba en la media hora siguiente.

El nodo nuevo no hace nada de eso: es un envío de flujo, respeta la pausa del piloto y no la arma.

Campos:

• assets — la lista de archivos, en orden. Cada entrada acepta { "id": "<id de la mediateca>" } o { "url": "https://…" }. Con id, el tipo real del archivo se resuelve al ejecutar, que es lo que hace que un audio llegue como nota de voz y no como archivo descargable. Con url puedes encadenar la salida de image.generate, voice.generate o video.generate. Máximo 10.
• body — texto opcional que acompaña; llega como un mensaje aparte, después de los archivos.
• recipient_contact_ref — opcional; en flujos iniciados por un contacto se autoresuelve.

Cada archivo sale como un mensaje propio, en el orden de la lista: WhatsApp no acepta varios adjuntos en un mismo mensaje. En la conversación del CRM queda una sola fila con todos los adjuntos, igual que un mensaje con archivos escrito desde la bandeja.

La API pública se mantiene en 329 operaciones; no cambian rutas, nombres, permisos ni formas de respuesta.

Una integración ya no le escribe encima a tu asesor

Cuando una persona responde desde la bandeja de Meteor, el piloto automático queda en pausa por los minutos que tengas configurados en Ajustes → Conversaciones. Hasta hoy esa pausa solo frenaba al Met del webhook: los envíos hechos con API key salían igual, por encima de la conversación que tu asesor estaba atendiendo.

A partir de esta versión, los envíos autenticados con API key son automáticos y respetan esa pausa:

• POST /contacts/{contactId}/messages
• POST /contacts/{contactId}/messages/template
• POST /channels/{channelId}/whatsapp/send-reply, send-template, send-buttons, send-list, send-location y send-contact

Si el contacto está silenciado —piloto apagado, pausa vigente, o chat en «Hablar con humano»— la llamada devuelve 409 con code: "autopilot_silenced" y no se envía ni se guarda nada. La respuesta incluye reason (autopilot_off, autopilot_paused o human_requested) y contact_id, para que tu integración pueda reintentar más tarde o registrar por qué no salió.

Dos cosas que no cambian:

• Los mismos endpoints llamados desde la sesión del panel siguen siendo una intervención humana: salen siempre y pausan el piloto.
• Los recordatorios programados de la Agenda salen aunque haya una pausa vigente: son un compromiso que ya se le prometió a tu cliente.

Y una que mejora: un envío con API key ya no pausa el piloto. Antes, una integración que mandaba varios mensajes seguidos dejaba una pausa que después se tragaba las respuestas del cliente durante media hora.

La API pública se mantiene en 329 operaciones; no cambian rutas, nombres, permisos ni formas de respuesta.

Los grupos reparten chats y los socios declaran su origen

El contrato público incorpora PATCH /agent-groups/{id}/auto-assign para activar o desactivar el reparto round-robin de chats entre los miembros de un grupo. La respuesta del grupo ahora también expone auto_assign, apagado por defecto.

El contrato de Partners permite enviar origin al vincular un socio, con los valores OWN o ASSIGNED. Así, la API puede distinguir si el socio fue conseguido directamente por el Máster o asignado por METEOR.

La API pública pasa de 328 a 329 operaciones. Las rutas existentes conservan sus nombres, permisos y respuestas; los clientes que no usen estas capacidades no necesitan cambiar sus llamadas.

Una tarea es un checklist de personas — se retiran la ejecución y los disparadores

Una tarea deja de ser un procedimiento que se corre y pasa a ser lo único que se usaba de ella: un checklist que reparte trabajo entre las personas del equipo. Se van la ejecución, las corridas, las aprobaciones y los disparadores del lado tarea.

Esto es un cambio mayor: doce operaciones dejan de existir. Una llamada a cualquiera de ellas responde 404.

Endpoints retirados

El CRUD de tareas y de pasos —crear, listar, editar, reordenar, marcar, comentar, adjuntar contexto y entregables— no cambia.

Qué cambia en un paso

Un paso ya no declara cómo se ejecuta. Salen del recurso:

• type (prompt / skill / approval / human_task)
• prompt, skill_id, skill_input_mapping
• approval_message, requires_approval
• delay_seconds, max_retries, output_format
• assigned_to_met_id

Queda lo que describe el trabajo: name, description, assigned_to_user_id, status y result_content.

status de un paso ahora es pending o completed. Los estados de corrida —running, failed, waiting_for_approval, approved, rejected— no se escriben más; los pasos que los tenían quedaron en pending, salvo approved, que pasó a completed porque significaba lo mismo.

Un paso se asigna a una persona. assigned_to_met_id no existe; la tarea entera sí sigue pudiendo tener un Met responsable (responsible_met_id).

Si tu paso guardaba la instrucción en prompt y no tenía description, ese texto se copió a description: no se perdió nada.

Qué cambia en una tarea

execution_config sale del recurso — en la práctica siempre valió {}.

Las tareas que quedaron en running o failed por una corrida vieja pasaron a pending. paused, cancelled y completed se respetan: esos los mueve una persona.

Automatizaciones y webhooks

POST /automations ya no acepta action_kind: "task" — responde 400. Y el default, que era "task" cuando no se mandaba nada, ahora es "flow".

Un webhook entrante ya no se puede crear con binding_type: "task"; queda "generic". El evento se registra igual, y para actuar sobre él se conecta un flujo.

Los disparadores hacia una tarea se borraron. Los de flujo, campo IA y procesos administrados no se tocaron.

Herramientas MCP

Se van met_execute_task y met_get_task_execution del servidor MCP externo, y meteor_execute_task, meteor_set_task_trigger, meteor_get_task_execution y meteor_complete_task_step de las tools internas del Met.

meteor_set_step_result se queda: un Met que hizo parte del trabajo sigue pudiendo dejar el resultado en el paso.

Si automatizabas algo con esto

Lo que ejecutaba pasos en cadena son los Flujos. Un flujo se dispara por fecha, recurrencia o evento, y hace lo que hacía una tarea agéntica, pero con un editor y un registro de corridas propios. La migración es rehacer el procedimiento como flujo y conectarle el disparador que tenía la tarea.

El contrato ya dice a quién escribirle

El bloque info de openapi.json traía contact: {} — el campo estaba, vacío. Para quien genera su cliente del contrato, ese es el único lugar donde mirar cuando algo no cuadra y no hay a quién preguntarle; y varias herramientas que leen specs lo muestran en su portada, así que la nuestra salía en blanco.

Ahora los dos contratos declaran contacto:

• API pública — hola@meteor.com.co y la documentación en developers.meteor.com.co.
• API de Partners — el mismo correo, con la documentación de partners.

Es el correo que ya atiende el resto del sitio: no es una casilla nueva.

No cambia nada de la API. Las mismas 328 operaciones públicas con sus rutas, parámetros, respuestas y permisos, y el mismo contrato 2.47.0 — solo que ahora dice quién está del otro lado. No necesitas tocar tus llamadas.