Novedades de la API

Las credenciales salen de dos respuestas, y una lista deja de ser global

Dos endpoints de lectura estaban devolviendo credenciales guardadas, y uno de ellos devolvía además datos de workspaces que no eran el tuyo. Los dos quedaron acotados hoy, sin ciclo de deprecación: no se le da seis meses de aviso a una respuesta que nunca debió llevar ese campo.

GET /skills/all ahora es de tu workspace

Antes leía la tabla entera sin filtrar por workspace. Ahora devuelve solo las habilidades activas de la cuenta a la que pertenece tu API key, y ya no incluye el objeto credentials.

Si tu integración contaba las filas de esta respuesta, va a contar menos. Es el arreglo, no una regresión: las filas que faltan nunca fueron tuyas.

GET /mcps/active ya no trae los valores de las credenciales

La respuesta pasó de ser la fila cruda de configuración a una proyección explícita. Lo que sí sigue viajando es mcp_data.credentials_required —los nombres de las credenciales que cada conexión necesita, que es lo que se usa para pintar un formulario— y lo que deja de viajar son los valores.

Un scope de lectura como integrations:read no debería alcanzar un secreto, y alcanzaba.

Las habilidades del workspace tampoco las devuelven

Cinco respuestas del catálogo de habilidades venían trayendo el objeto credentials de cada configuración:

GET  /workspaces/{id}/marketplace/skills     ← dentro de workspace_config
GET  /workspaces/{id}/skills/active
POST /workspaces/{id}/skills/{skillId}/activate
POST /workspaces/{id}/skills/{skillId}/deactivate
PUT  /workspaces/{id}/skills/{skillId}/credentials

La primera es la que más incomoda: skills:read es un permiso de lectura y alcanzaba un secreto. La última hacía eco de lo que acabas de guardar, que tampoco hace falta — ya lo tienes tú, y la respuesta la ve todo lo que esté en el camino.

Aquí el contrato no cambia: WorkspaceSkillConfigDto nunca declaró ese campo. Lo que cambia es que ahora la respuesta se parece al contrato.

Los enlaces entre ítems validan a qué workspace pertenecen

GET /items/{itemId}/links, POST /items/{itemId}/links y DELETE /item-links/{linkId} ahora verifican que el ítem sea de tu workspace antes de responder. Un id ajeno devuelve 404, no 403: la API nunca confirma que exista algo que no puedes ver.

En el POST se validan los dos extremos del enlace. Es deliberado: la lectura embebe el ítem destino, así que un enlace apuntando fuera de tu workspace habría convertido cada lectura posterior en una fuga.

Si generas tu cliente del contrato

Los schemas ActiveSkillResponseDto y ActiveMcpResponseDto pasaron de abiertos a cerrados: declaran exactamente los campos que viajan. Si tu generador aceptaba propiedades extra en estos dos, ya no hay ninguna que aceptar.

Devolverle una cuenta gestionada a tu cliente

Una cuenta que aprovisionaste y venías pagando ahora puede pasar a manos de tu cliente, sin que él pierda nada de lo que tiene adentro:

POST /workspaces/{id}/handover

Desde ese momento la licencia se le cobra a él, tú dejas de pagarla, y esa cuenta vuelve a generarte comisión — el descuento que la reemplazaba termina con el traspaso.

Tres cosas que conviene saber antes de llamarlo:

• Tu cliente necesita su propio medio de pago guardado. Si no lo tiene, la llamada responde 409 y no cancela nada. Es a propósito: soltar la cuenta antes de que él pueda pagarla la dejaría sin servicio, y el que se queda sin Met es él, por algo que no pidió.
• La energía que le cargaste se queda con la cuenta. Ya es servicio entregado; no se descuenta ni se devuelve.
• Se puede reintentar sin miedo. Si la llamada se corta a mitad de camino, repetirla termina el traspaso en vez de crear una segunda suscripción.

Tu cliente también puede pedirlo desde su propia facturación, sin pasar por ti. No es un descuido: una cuenta gestionada sin salida propia sería una cuenta de la que él no puede irse.

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.