Novedades de la API

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.

Reintenta un mensaje de contacto sin enviarlo dos veces

POST /contacts/{id}/messages acepta ahora el campo opcional client_message_id, un UUID v4 generado por tu aplicación antes del primer intento.

Si la conexión se corta y no sabes si Meteor alcanzó a recibir el mensaje, repite la misma solicitud con el mismo UUID. Meteor devuelve el mensaje ya registrado y no vuelve a entregarlo al contacto. La respuesta indica este caso con deduplicated: true.

El UUID queda disponible como client_message_id en el mensaje devuelto y al consultar la conversación. No reutilices una misma llave con otro texto, adjuntos o contacto: Meteor responde 409 para evitar cruzar conversaciones.

El campo es opcional y aditivo; las integraciones existentes conservan su comportamiento.

La referencia te trata de tú en todas sus descripciones

Trece descripciones de la referencia, la mayoría de Contactos, te hablaban con voseo. Ahora usan el mismo español neutro que el resto de la documentación.

Esta corrección documenta el mismo contrato 3.4.0: no es una nueva versión de la API. Se conservan las rutas, los parámetros, los esquemas y los permisos, así que no necesitas cambiar tus llamadas. Si generas un cliente desde el contrato, solo cambian sus comentarios.

Borrar un campo de contacto ahora borra también su valor

DELETE /variables/field-definitions/{id} ya no se limita a quitar la definición del campo: además borra el valor de ese campo en todos los contactos del espacio de trabajo.

Antes el dato se quedaba guardado en cada contacto. Si luego creabas otro campo con el mismo identificador —lo normal cuando te equivocaste de tipo y lo creas de nuevo—, los valores viejos reaparecían con el tipo anterior.

Vaciar el valor cuenta como un cambio del contacto, así que recibirás un contact.updated por cada contacto que tenía el dato. El valor llega en null.

Nuevo 409

Si una automatización activa observa el campo, la llamada responde 409 y no borra nada: vaciar el valor dispararía su condición en todos los contactos a la vez. El mensaje nombra las automatizaciones; desactívalas o cambia su condición y vuelve a intentar.

Ahora sabes desde dónde salió cada respuesta, y solo te llegan mensajes reales

Si tu integración sigue las conversaciones de WhatsApp, ahora puedes saber quién respondió y desde dónde sin cruzar datos por tu cuenta. El evento contact.message.sent trae el campo sent_from:

Tus métricas quedan limpias. Antes, las notas internas de la conversación —«Chat asignado a…», «Estado cambiado…», «Etiqueta agregada…»— también llegaban como mensajes enviados, aunque el contacto nunca las veía. Eran cerca de una de cada cinco entregas de este evento. Ya no te llegan: si cuentas respuestas o tiempos de atención, ahora cuentas solo lo que el contacto recibió.

No te pierdes las respuestas al conectar. Al crear un endpoint con contact.message.received, la consola te ofrece sumar contact.message.sent con un clic. Con solo el primero ves lo que escribe el contacto, pero no lo que se le responde.

Cuatro campos nuevos para leer los topes de un plan

Si tu integración pinta el estado de la cuenta o decide cuándo ofrecer una mejora de plan, ahora tienes cuatro datos que antes no estaban en el contrato. Todos son opcionales y aditivos: nada de lo que ya leías cambió.

Cuántas redes sociales admite el plan

Plan.social_accounts_max dice cuántas cuentas de red social —líneas de WhatsApp, cuentas de Facebook e Instagram, sumadas— puede tener conectadas el espacio de trabajo.

{ "slug": "oficina", "social_accounts_max": null }

null significa sin tope, y es lo que devuelven los planes de pago. Un plan que traiga 1 admite una sola cuenta entre las tres redes, no una por red.

Es un techo distinto de los que ya conocías: wa_numbers_included cuenta números de WhatsApp y meta_accounts_included cuenta cuentas de Meta, cada uno contra su propia red. Este mira el total. Cuando lo alcanzas, conectar otra cuenta responde 403 con error: "social_accounts_quota" y un usage que trae el desglose por red.

Cuándo el tope de contactos no bloquea

Plan.contacts_limit_soft distingue dos formas de aplicar max_contacts:

Con el tope blando, un contacto entrante que llega por encima del límite no se pierde: se guarda en espera y se incorpora cuando el cupo vuelve a alcanzar.

Dónde aterriza una prueba que vence

WorkspaceSubscription.fallback_plan_id es el plan al que pasa la suscripción cuando se le acaba la prueba, en vez de quedar inactiva. null —el valor de casi todas— es el comportamiento de siempre: la prueba vence y la cuenta se bloquea hasta que se elija un plan.

Y en GET /billing/access, landed_on_fallback te avisa de la ventana en la que la prueba ya venció y la cuenta ya opera con el plan de destino, aunque la suscripción todavía diga trial:

{
  "subscription_status": "trial",
  "landed_on_fallback": true,
  "plan_slug": "<el plan de destino>",
  "limits": { "contacts_max": 100 }
}

Cuando landed_on_fallback es true, manda el plan que viene en la respuesta, no el subscription_status. plan_id, plan_slug y limits ya son los del plan de destino; el estado de la fila se pone al día en el corte siguiente. Si tu integración decide por subscription_status, vas a ver una prueba vencida donde hay una cuenta que funciona.

Crea plantillas de WhatsApp y edita tus atajos por API

Lo que hasta hoy solo se podía hacer desde el panel ya se puede hacer por API.

Plantillas de WhatsApp

curl -X POST https://api.met.meteor.com.co/api/v1/channels/42/templates \
  -H "Authorization: Bearer $MET_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "recordatorio_cita",
    "language": "es",
    "category": "UTILITY",
    "components": [
      { "type": "BODY", "text": "Hola {{1}}, te recordamos tu cita del {{2}}." }
    ]
  }'

Y DELETE sobre la misma ruta, con el name en el cuerpo, para borrarla. Las dos piden el permiso nuevo channels:manage.

Una plantilla pertenece a la cuenta de WhatsApp, no al número. Si tienes varias cuentas conectadas, la plantilla queda disponible para todos los números de aquella en la que la creaste. Omitir waba_id la crea en tu cuenta primaria, que puede no ser la del número desde el que piensas enviar; los waba_id conectados te los devuelve GET /channels/{id}/templates.

Una clave de prueba no alcanza. Crear una plantilla manda una solicitud real a revisión de Meta sobre la cuenta de tu cliente, así que channels:manage está entre los permisos restringidos en modo de prueba.

Hay un tope: 25 creaciones por cuenta y por hora. No es un número decorativo: una plantilla rechazada le baja la calificación de calidad a la cuenta de WhatsApp, y esa calificación es de tu cliente, no tuya. El 429 sale con rate_limited.

Ahora te enteras cuando Meta resuelve

La creación vuelve de inmediato con template_status: "PENDING". Meta decide después, y lo normal es que tarde. Hay tres eventos nuevos para no tener que estar preguntando:

El tercero es el que conviene no ignorar. Ahí caen las plantillas que venían funcionando y dejaron de hacerlo, que operativamente es peor que un rechazo: un rechazo lo descubres cuando vas a mirar, una pausa te corta envíos en curso.

Los tres piden channels:read.

Atajos

Los atajos —las respuestas guardadas del chat— también salen a la API, con CRUD completo en /quick-replies. Leer pide conversations:read; crear, editar y borrar piden el permiso nuevo conversations:write.

curl https://api.met.meteor.com.co/api/v1/quick-replies \
  -H "Authorization: Bearer $MET_API_KEY"