Novedades de la API

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.

Las 328 operaciones ya explican qué hacen

Hasta hoy, 255 de las 328 operaciones públicas traían solo un título de una línea. El resumen te decía qué era la operación, pero no lo que necesitas para llamarla bien: qué devuelve, cuál es el valor por defecto, qué pasa si la repites y con cuál se encadena.

Todas tienen ahora una descripción, y está en el contrato — así que la lee igual tu editor, el SDK y un agente que descubra la API por openapi.json, sin pasar por las guías.

Lo que se documentó es lo que se aprende a golpes:

• PUT reemplaza y PATCH fusiona. En items, PUT pisa data completo y las claves que no mandes se pierden; PATCH solo toca lo que le pases.
• Qué es destructivo. Borrar un item o un contacto es definitivo, y borrar un contacto se lleva también sus mensajes. Queda dicho en la operación, no en una nota aparte.
• Los valores por defecto y los topes, en el mismo lugar donde se eligen: los 50 de una página, los 200 de tope, las 500 filas de un lote de contactos.
• Cuándo una llamada cambia de forma. POST /runs con stream: true deja de responder JSON y pasa a un stream SSE; el esquema publicado describe el otro caso.
• Qué te va a bloquear. Un proceso administrado solo acepta activarse o pausarse y no se puede eliminar; un mensaje libre de WhatsApp solo se entrega dentro de la ventana de 24 horas, y fuera de ella hace falta una plantilla.
• Dónde mirar cuando algo no aparece. El pool de tools de un Met explica por qué el modelo no ve tu Función o tu habilidad, y el log de entregas distingue el evento que nunca salió del que salió y tu servidor rechazó.

No cambia nada de la API. Se conservan las mismas 328 operaciones con sus rutas, parámetros, respuestas y permisos: es el mismo contrato 2.47.0 mejor explicado. No necesitas tocar tus llamadas ni pedir permisos nuevos.

El tipo de campo page se retira del catálogo

page deja de ser un tipo válido en POST /collections/{id}/fields y en PATCH /fields/{id}. El catálogo queda en:

text · number · currency · email · date · datetime · boolean · url
select · prompt · usuario · contact · sitio · image · file

Un campo page guardaba la referencia a una página del módulo Páginas, que se retiró entero. Lo reemplaza Sitios web, que es donde se publica contenido hoy: un campo sitio referencia un sitio y una página sitio se edita en su propio módulo.

Si tenías campos page

Se convirtieron a text conservando el nombre que la página tenía guardado, así que el valor sigue ahí y se puede leer. Lo que ya no hay es la relación: el campo dejó de apuntar a una entidad y pasó a ser una etiqueta.

Si mandas type: "page"

La petición responde 400 con invalid_request_error. No hay ciclo de deprecación porque no queda nada al otro lado de la referencia: el módulo, sus páginas y su vista HTML se fueron en la misma versión.

Ejecuta una extracción sin herramientas ni contexto del workspace

POST /workspaces/{workspaceId}/runs admite tool_policy: "none" para trabajar únicamente con el input, sus adjuntos y las instrucciones del Met vinculado. No carga skills, integraciones, historial previo, variables ni contexto dinámico del workspace. Si falta un Met válido, falla: no pasa al orquestador. Un intento de invocar herramientas detiene la ejecución sin despacharlas.

Los adjuntos admitidos son PDF e imágenes (native_attachment_kinds: ["pdf", "image"]) mediante URL HTTPS firmada del almacenamiento configurado de Meteor. No consulta la caché de extracción ni OCR. Audio y documentos que necesitan conversión se rechazan antes de crear un run: pega su texto o transcripción como input.

Antes de usar esta política consulta GET /workspaces/{workspaceId}/runs/capabilities con la misma key y workspace. Requiere runs:execute, no ejecuta un Met ni consume Energía, y responde policy_version: 1 y tool_policies: ["none"]. La respuesta no se almacena en caché. Los SDK ofrecen met.runs.capabilities() y conservan tool_policy tanto en ejecución normal como en streaming.

El run conserva metadata.tool_policy: "none" en POST y GET. Verifica también status: "completed" antes de consumir su salida. Omitir la política conserva el comportamiento anterior. Durante un despliegue mixto, el preflight no prueba que otra instancia vaya a atender el POST: activa consumidores solo después de verificar que todas las instancias aplican esta política.

Corrección de los esquemas auxiliares de la referencia de Partners

La definición descargable de Partners y su copia en el portal actualizan sus esquemas auxiliares. Esta corrección documenta el mismo contrato 2.47.0: no es una nueva versión de la API.

Se conservan las mismas 37 operaciones, sus rutas, parámetros, respuestas y requisitos de autenticación. No necesitas cambiar tus llamadas ni solicitar permisos nuevos. La presencia de un esquema auxiliar no habilita una operación adicional con tu key.

Toda llamada a tu código viene firmada, sin que tengas que configurar nada

Cuando registras tu API como una Función IA de tipo HTTP, el Met la invoca mandándole una petición a tu servidor. Hasta ahora esa petición solo iba firmada si configurabas un secreto a mano, y quien no lo hacía dejaba su endpoint abierto: cualquiera que descubriera la URL podía hacerse pasar por Meteor y disparar tu código con los argumentos que quisiera.

Eso se acabó. Ahora toda llamada saliente va firmada, siempre.

Meteor genera un secreto propio para tu workspace y lo deja en una variable reservada, MET_TOOL_SIGN_SECRET, que ves y cambias desde Variables como cualquier otra. Si ya tenías tu propio secreto configurado en la Función (sign_secret_variable), ese sigue mandando y no cambia nada para ti.

La firma viaja en la cabecera X-Met-Signature, con el mismo esquema de los eventos salientes:

X-Met-Signature: t=<unix_ts>,v1=<hex(hmac_sha256(secreto, "<t>.<cuerpo>"))>

El timestamp va dentro del cálculo, así que una petición vieja no se puede reenviar con una hora nueva. Verifícala con met.tools.createHandler(secreto) del SDK en vez de escribir el HMAC a mano.

Si ya tenías Funciones HTTP registradas, no se rompe nada: reciben una cabecera de más y tu servidor la ignora hasta que decidas verificarla. Te recomendamos que la verifiques, que es justamente lo que esta cabecera te permite hacer.

Tu aplicación se registra sola para conectarse a Meteor

Hasta ahora, para que una aplicación se conectara a una cuenta de Meteor por OAuth, alguien tenía que entrar a Ajustes → Desarrolladores y crearla a mano. Eso deja por fuera a los clientes que descubren un servidor MCP y esperan poder registrarse solos, que es como funcionan Claude y ChatGPT.

Ya se puede. Meteor implementa registro dinámico de clientes (RFC 7591), y lo anuncia en su documento de descubrimiento como registration_endpoint:

curl -X POST https://api.met.meteor.com.co/oauth/register \
  -H "Content-Type: application/json" \
  -d '{"client_name":"Mi App","redirect_uris":["https://mi-app.com/callback"]}'

Te devuelve client_id y client_secret de una vez, sin sesión y sin intervención de nadie.

Registrarse no da acceso a nada por sí solo: para que exista un token, alguien de la cuenta tiene que iniciar sesión en Meteor y aprobar los permisos. Una app que se registró sola alcanza los permisos del servidor MCP, no todos los de la plataforma, y la pantalla de consentimiento la muestra como no verificada — distinta de una app revisada por Meteor.

Las redirect_uris deben ser https, salvo direcciones locales para aplicaciones de escritorio. No se aceptan comodines.