Novedades de la API

Cargar energía sin abrir un enlace de pago

POST /workspaces/{id}/recharge acepta off_session: true y cobra directo a tu medio de pago guardado, sin devolver un enlace que alguien tenga que abrir:

POST /workspaces/42/recharge
{ "amount_usd": 100, "off_session": true }

→ 200 { "object": "energy_charge", "status": "succeeded",
        "payment_intent_id": "pi_…", "acreditado": false }

acreditado viene en false a propósito, incluso cuando el cobro salió bien. El saldo lo acredita el webhook del pago, que es el único que sabe que el dinero entró de verdad; sumarlo en esta respuesta daría saldo por un cobro que todavía se puede revertir. Si necesitas confirmar, consulta el saldo de la cuenta unos segundos después.

Sin la bandera todo sigue igual: devuelve el enlace de pago de siempre, así que nada de lo que ya tengas escrito cambia. Y si pides off_session sin medio de pago guardado, responde 409 diciendo cuál es la salida.

Pasar una cuenta aprovisionada a un plan, cobrado a tu medio de pago

Si aprovisionas cuentas para tus clientes, ahora puedes pasarlas de Tech Partner a un plan comercial y que la licencia se cobre a tu tarjeta:

POST /workspaces/{id}/subscription
{ "plan_slug": "estudio", "billing_cycle": "monthly" }

La respuesta trae el descuento aplicado, su duración y el nivel con el que se calculó.

El descuento reemplaza tu comisión, no se suma a ella. Es el espejo exacto de lo que habrías cobrado: el mismo porcentaje, durante el mismo tiempo. Si tienes una tasa negociada, se usa esa y no la de tu nivel. Por esas cuentas no vas a ver comisión, y en el ledger queda dicho por qué.

Dos cosas que conviene saber antes de llamarlo:

• Necesitas un medio de pago guardado. Sin él responde 409: una suscripción sin con qué cobrarla nace impaga, y el que sufre ese estado es tu cliente, que no puede resolverlo porque la factura no es suya.
• Una cuenta solo puede estar gestionada una vez. Un segundo intento responde 409 en vez de duplicar el descuento.

La energía sigue cobrándose al margen del plan del cliente, así que pasar una cuenta a un plan también le baja lo que consume — que suele ser la razón real para hacerlo.

Un Tech Partner ya puede dejar su tarjeta en archivo

Si aprovisionas cuentas para tus clientes, ahora puedes guardar un medio de pago a tu nombre y dejar de abrir un enlace de cobro cada vez.

POST /partner/payment-method/setup
{ "success_url": "https://tu-panel.com/ok", "cancel_url": "https://tu-panel.com/no" }

→ 200 { "checkout_url": "https://checkout.stripe.com/…", "session_id": "cs_…" }

El enlace abre un Checkout en modo setup: no cobra nada, solo deja la tarjeta guardada. Por tu integración nunca pasa un dato de tarjeta.

Para saber qué hay guardado, GET /partner/payment-method responde la marca, los últimos cuatro dígitos, el vencimiento y si ya venció. Se lee de la fuente en cada llamada, así que si cambias la tarjeta el cambio se ve enseguida.

Los dos van con el scope nuevo partner:billing:manage, aparte de workspaces:provision a propósito: una key que le entregas a un integrador para que te cree cuentas no debería poder, con el mismo permiso, cambiar la tarjeta con la que pagas todo. Como cualquier scope que mueve dinero, no funciona en modo test.

Seis recetas de punta a punta y la documentación servida en markdown

Seis recetas nuevas arman un caso completo, de la primera línea a producción, con el código listo para copiar: un agente que contesta WhatsApp con tu lógica en el medio, sincronizar un sistema externo con colecciones, recibir eventos firmados en tu backend, ejecutar un Met desde GitHub Actions, mostrar un run en vivo en tu UI y una tarea que pide aprobación humana. Cada una declara con qué se arma, qué partes de la API toca y qué scopes necesita tu key.

La documentación también se sirve en markdown, para cuando quien la lee es tu agente. Cambia .html por .md en cualquier guía, o pide Accept: text/markdown sobre la misma URL y recibes el texto sin la página alrededor. llms.txt trae el mapa del portal y llms-full.txt las guías completas concatenadas.

Cada guía muestra ahora cuándo se actualizó por última vez, se puede copiar entera como markdown desde su encabezado, y todos los bloques de código del portal tienen botón de copiar.

"meteor-api: un pack de skills para los agentes que escriben código"

El servidor MCP entrega las herramientas; lo que le faltaba a un agente que programa contra Meteor era el criterio de cuál usar, en qué orden y qué decide el servidor por él. meteor-api es ese criterio, empaquetado en seis sub-skills —Mets, CRM, tareas, datos, automatizaciones y plantillas— que se instalan en .agents/skills/ y sirven en cualquier cliente que lea esa carpeta:

curl -fsSL https://developers.meteor.com.co/skill-pack/install.sh | sh

El pack se arma del mismo catálogo de herramientas que expone el servidor MCP y de las guías publicadas, así que dice lo mismo que la referencia.

Se llama meteor-api y no skills para no confundirlo con las Skills del producto, que son otra cosa: capacidades que activas y vinculas a un Met.

Además, catorce herramientas del servidor MCP ahora explican lo que antes había que descubrir usándolas: qué límite tiene la respuesta, qué campos vienen recortados, cuál es la herramienta que sigue y cuándo una operación debita Energía.

Procesos administrados visibles y controlables desde Automatizaciones

La API pública de Automatizaciones ahora refleja los procesos administrados por el sistema junto con las tareas, flujos y campos de IA del workspace. Una integración puede distinguirlos mediante is_system_managed, consultar su última ejecución y, cuando el proceso lo permite, ejecutarlo manualmente, revisar su historial o ajustar su horario seguro.

Los nuevos controles conservan los scopes granulares de Automatizaciones y no permiten editar la lógica interna del proceso administrado.

Creación de cuentas de Met desde tu producto

• La API pública incorpora POST /workspaces para crear una cuenta de Met con su dueño. Es exclusivo de las llaves de partner con el permiso workspaces:provision, disponible para los Tech Partners aprobados.
• La cabecera Idempotency-Key es obligatoria en esta operación: reintentar con la misma clave devuelve la cuenta que ya se creó, no una nueva.
• POST /workspaces/{workspaceId}/recharge (permiso workspaces:recharge) abre un enlace de pago para cargarle energía a una cuenta que creaste. Solo funciona sobre tus propias cuentas.

La cuenta nace con el plan Tech Partner y sin energía, así que la respuesta incluye operational: false mientras el saldo esté en cero. La energía la paga siempre la cuenta que la consume: carga saldo antes de que tu cliente empiece a usarla. La recarga no acredita el saldo al instante — devuelve un enlace de pago y la energía entra cuando el pago se completa. El dueño recibe por correo un enlace para definir su contraseña — nunca la defines tú.

Cada nivel de partner tiene un cupo mensual de cuentas. Al agotarse, la operación responde 403 indicando el cupo, el consumo del mes y cuándo se reinicia.

Cancelación de flujos y contrato actualizado de Red Máster

• La API pública incorpora POST /workspaces/{workspaceId}/flow-runs/{runId}/cancel para detener el agendado de nuevos nodos y marcar una ejecución como cancelada.
• El contrato de Partners refleja la terminología y las operaciones vigentes de Red Máster, incluidas las solicitudes, vinculaciones y designaciones.

Cancelar una ejecución no interrumpe una generación que el proveedor ya haya comenzado; esa operación termina y conserva su cobro correspondiente.

La API de conversiones documenta sus errores de operación

Las operaciones públicas de conversiones de contacto y conversiones web ahora documentan los errores 403, 404 y 409 que pueden devolver. Las integraciones pueden distinguir permisos insuficientes, recursos no disponibles y conflictos o duplicados sin depender de respuestas no documentadas.

La API de conversiones documenta sus errores de acceso y conflicto

Las operaciones POST /conversions y POST /conversions/web ahora describen en OpenAPI las respuestas de error que una integración puede recibir:

• 403 cuando la credencial no tiene acceso a la operación.
• 404 cuando el recurso asociado no existe dentro de su alcance.
• 409 cuando la conversión entra en conflicto con el estado existente.

Este ajuste no cambia el formato de las solicitudes ni de las respuestas; hace que la referencia y los clientes generados reflejen el contrato vigente.

La API de Partners ya documenta respuestas y errores de acceso reales

Las 37 operaciones de met.partner.* ahora describen su respuesta exitosa: clientes, comisiones, payouts, oportunidades, proyectos, hilos y tickets. El OpenAPI deja de mostrar respuestas vacías, así que la referencia y los clientes generados pueden conocer la forma curada de cada recurso.

También documentamos los errores que una integración puede recibir de verdad:

• 403 cuando falta un scope, una capacidad no está habilitada o el recurso queda fuera de la cartera de la key.
• 404 cuando un recurso no existe dentro de ese alcance, sin revelar recursos de otro tenant.
• 409 en operaciones que mutan estado, incluidos los conflictos de Idempotency-Key.

Las requests autenticadas con API key devuelven ahora la taxonomía pública de error también cuando una validación o regla de dominio usa una excepción estándar: type, code, message y request_id. Las sesiones del panel conservan su formato anterior.

Acceso API por plan mensual y nuevo plan Tech Partner

• Las API keys se pueden crear y administrar desde el workspace antes de contratar un plan.
• Para usar una key, el workspace operado debe tener un plan mensual vigente; también cuentan el trial y los planes bonificados.
• Las keys de Partner validan el plan del workspace atribuido y ya no pueden operar un cliente sin suscripción activa.
• Los límites de RPM y cuota mensual se resuelven desde el plan vigente al ejecutar cada key.
• Tech Partner es un plan restringido de USD 0 de cargo fijo mensual, habilitado únicamente por Meteor para alianzas aprobadas; la Energía se cobra a tarifa premium.