Saltar al contenido principal

Changelog

Cambios relevantes en la API pública, en los payloads de webhook y en las tools de MCP, más recientes primero. Fechas en UTC.

2026-10-25​

  • Añadido — tool MCP me (título Get current identity): devuelve la persona, la organización y el alcance del token de la conexión, con el mismo JSON de GET /v1/me. Cualquier token MCP válido puede llamarla — sin scope de recurso ni permiso — por eso tools/list siempre la lista. Aditivo.

2026-10-22​

Servidor MCP, más el bucket de rate limit que comparte con la API REST.

  • Añadido — cada tool del MCP trae un title legible (List e-mails, Replay webhook delivery), en el descriptor de tools/list y en annotations.title. El cliente muestra el título en lugar del identificador. Aditivo.
  • Modificado — el metadata del recurso protegido anuncia en scopes_supported solo lo que el authorization server concede a un cliente registrado por el flujo OAuth: un scope inbox/… por recurso, más read. inbox/all y write salieron de la lista — el cliente que los pedía era rechazado en /oauth/authorize.
  • Cambiado — el límite de solicitudes del servidor MCP y de la API REST cuenta por persona dentro de la organización (sub + org), en un único presupuesto compartido. Todo token de la misma persona consume de él — un token nuevo nunca lo reinicia — y la misma persona en otra organización pasa a tener su propio presupuesto (antes el bucket era solo el sub, atravesando organizaciones). Los límites no cambian.
  • Cambiado — una ruta desconocida en el host MCP (https://mcp.inbox.kobana.com.br/cualquier-cosa) responde 404 con el cuerpo JSON { "error": { "code": "not_found", "message": "not_found" } } en cualquier método, en lugar de una página HTML. Ver Endpoints.
  • Documentado — el servidor MCP lee el token solo de Authorization: Bearer; un token en la query string (?access_token=) se ignora y la solicitud recibe el desafío 401. Ese ya era el comportamiento; ahora está dicho en Autenticación y cubierto por tests. Del mismo modo, limit, cursor y sort solo se toman de sus argumentos nombrados — las claves no declaradas (per_page, page, un objeto filters) se descartan (Paginación).
  • Cambiado (incompatible) — las tools MCP destructivas solo se ejecutan después de que el servidor las confirme con el usuario. Un cliente que no puede confirmar — protocolo 2025, o 2026-07-28 sin formularios de elicitation — recibe el error de tool confirmation_required y no se ejecuta nada (antes, la tool se ejecutaba y la confirmación quedaba a cargo del manejo de destructiveHint del cliente). Si el servidor no puede registrar la confirmación, la respuesta es confirmation_unavailable.
  • Cambiado (incompatible) — emails_reprocess, webhooks_test, webhooks_deliveries_replay e inboxes_add_recipient pasan a ser destructivas (destructiveHint: true): las tres primeras envían algo hacia fuera o vuelven a ejecutar un agente que puede responder, la última cambia quién puede enviar a una inbox. emails_reprocess, webhooks_test, webhooks_deliveries_replay y webhooks_regenerate_secret ahora informan idempotentHint: false.
  • Cambiado — una confirmación ejecuta la acción una sola vez: enviar de nuevo la misma llamada confirmada responde confirmation_replayed sin ejecutar nada. Para volver a preguntar, llama a la tool sin requestState.
  • Cambiado — el body de la solicitud MCP está limitado a 1 MB; por encima, la respuesta es 413 con el error JSON-RPC -32600 (Request body too large (limit 1048576 bytes)), comprobado en el Content-Length antes de la autenticación y garantizado en la lectura del propio stream. Ver Errores.

2026-10-21​

Solo el servidor MCP — la API REST no cambia.

  • Cambiado (breaking) — Autenticación MCP: el servidor MCP ahora exige un token emitido para él — aud es la URL del servidor MCP (https://mcp.inbox.kobana.com.br), no la audience de la API (inbox/prd). Un token emitido para la API REST se rechaza con 401 invalid_token, y lo inverso también vale; un token que nombra más de una audience se rechaza. Conéctate por el flujo OAuth (el cliente solo necesita la URL) o con un token personal creado con el uso MCP.
  • Cambiado (breaking) — todo token MCP se trata como de una persona, sea cual sea el src que lleve: siempre se aplican los permisos de la persona en el dashboard, y una persona que no es miembro de la organización no alcanza nada (403, no_membership). Antes, un token con src=system o src=api pasaba solo por el scope.
  • Añadido — revisión de protocolo 2026-07-28, junto a 2025-06-18 y 2025-03-26, decidida por el body de la solicitud: server/discover, el envelope _meta, -32020 para headers que no coinciden con el body y 404 para un método desconocido. Una versión no soportada ahora es 400 con el error JSON-RPC -32022 y la lista de las soportadas, en lugar de unsupported_protocol_version.
  • Añadido — resources bajo kobana://inbox/ (correos, inboxes, agentes, ejecuciones, webhooks, eventos, el catálogo de modelos y el uso), cuatro prompts de solo lectura y completions para sus argumentos. Cada uno se alcanza con el mismo scope y permiso que la tool que tiene detrás.
  • Añadido — en 2026-07-28, una tool destructiva pide primero al usuario que confirme (resultType: "input_required"); rechazar responde user_declined. Los clientes sin elicitation, y las revisiones de 2025, se comportan como antes.
  • Añadido — el nivel de acceso del token (read, write, all) se respeta junto a inbox/… + write: con scopes de recurso en el token, los recursos definen el alcance y el nivel actúa dentro de ellos. Ver Scopes.
  • Cambiado — que el authorization server no esté disponible es 503 con Retry-After (antes 500); los intentos con token inválido se limitan por IP y reciben 429 al superar el límite. Los metadatos del recurso protegido nombran al authorization server por su emisor (issuer).

2026-10-15​

  • Añadido — Inbox.attachments_allow_rules: lista de adjuntos permitidos por extensión y/o expresión regular en el nombre del archivo, en create, update, upsert y en las tools MCP de inbox. Un adjunto fuera de la lista se ignora — el agente no lo ve, los límites attachments_max_* no lo cuentan y un paso de workflow que lo referencia falla antes de cualquier solicitud. El correo lo registra en metadata.ignoredAttachments. El valor por defecto null procesa todos los adjuntos, como antes. Aditivo.
  • Cambiado (comportamiento) — un adjunto de texto, o uno enviado al agente en base64, de más de 256 KB ahora llega al agente solo con su encabezado y (conteúdo não enviado: …), en lugar de su contenido. Los PDF y las imágenes no cambian. Antes, un adjunto ilegible grande (un .msg de Outlook, por ejemplo) podía superar el límite de entrada del modelo y hacer fallar la ejecución.

2026-10-07​

  • Agregado — todo webhook saliente ahora lleva X-Idempotency-Key. En el envío original y en cada reintento automático es el id del evento (SystemEvent.id, el mismo valor que X-Kobana-Event-Id), para que un endpoint que respeta claves de idempotencia procese el evento una vez y responda a las repeticiones con la respuesta original. Un replay manual envía una clave nueva y aleatoria, para que el destino lo trate como una entrega nueva en lugar de deduplicarlo contra lo que ese evento ya resolvió. Ver Headers. Aditivo.
  • Cambiado (comportamiento) — WebhookDelivery: un reintento programado ya no se envía cuando cualquier entrega del mismo evento al mismo webhook ya tuvo éxito, típicamente después de un replay manual. Antes, la cadena de reintentos de la entrega original seguía corriendo después de que el replay entregara el evento, y el destino podía recibir un intento más después de un 2xx. El next_retry_at de las filas failed anteriores ahora se limpia en ese momento. Ningún campo cambió de forma.

2026-09-30​

  • Cambiado (comportamiento) — los Workflows del agente ya no se detienen en el primer fallo. Todos los pasos se intentan; un paso que falla queda failed por sí solo y los siguientes siguen ejecutándose. Un paso que referencia a un paso que no tuvo éxito (falló o se saltó) queda skipped y nunca se envía, con error depends on step N, which did not succeed. La ejecución sigue quedando failed si algún paso falló, y su error ahora lista todos los fallos, uno por línea (step <posición>: <error>). Sin reintento, sigue siendo secuencial.
  • Añadido — failed_steps en los webhooks de workflow.run.failed (failedSteps en el system event): las posiciones de todos los pasos que fallaron. failed_step y error siguen describiendo el primer fallo.

failed_steps es aditivo y ningún campo cambió de forma — pero el cambio de ejecución es un cambio de comportamiento: una ejecución que antes se detenía en el paso 1 ahora también ejecuta los pasos independientes posteriores.

2026-09-29​

  • Añadido — Steps y placeholders: un paso request puede llevar form en lugar de body. Se envía como multipart/form-data, una parte por campo; los dos son excluyentes.
  • Añadido — espacio de nombres de placeholder ${{email.attachments.N}}: el N-ésimo adjunto del correo detrás del run. Como valor entero de un campo de form, se sube como parte binaria de archivo (bytes, nombre y content type del correo); dentro de cualquier string, se convierte en el base64 del archivo. .base64, .filename, .content_type y .size también están disponibles. Los bytes nunca pasan por el modelo.
  • Cambiado — los pasos de WorkflowRun ahora exponen request.form (null en un paso con body). Un campo de archivo se registra como un descriptor { attachment, filename, content_type, size }, y un adjunto referenciado como base64 dentro de request.body se guarda como [attachment N: …] en lugar de sus bytes.

Todo aditivo — nada existente cambió de forma o comportamiento.

2026-09-24​

  • Cambiado (breaking) — Autenticación: el token Bearer ahora es un access token RS256 emitido por el Authorization Server de Kobana, verificado contra la clave pública que publica. Los tokens firmados con el secreto HS512 compartido anterior ya no se aceptan. No cambia cómo envías el token — solo qué tokens verifican.
    • org pasa a ser obligatoria, y es la que acota tus datos. sub es la persona (users.public_id); el tenant es org (accounts.public_id). Un token sin org se rechaza en lugar de caer en sub — ese fallback no coincidiría con nada y respondería 403 a todo, sin nada que señale la causa.
    • iss ahora es la URL del Authorization Server (https://account[.{env}].kobana.com.br); aud es la URL de esta API (https://api.inbox[.{env}].kobana.com.br) y puede ser una lista, comparada por contiene.
    • exp pasa a ser obligatoria. Un token sin expiración se rechaza.
    • Nuevo modo de fallo 500 as_unavailable: no se pudo alcanzar nuestro Authorization Server. No es 401 a propósito — tu token puede ser perfectamente válido; reintenta en unos instantes.

2026-09-09​

  • Añadido — Workflows del agente: un agente ahora puede terminar su ejecución con un array workflow junto a result, y la plataforma lo ejecuta como una cadena de peticiones HTTP contra sus sistemas. Secuencial, se detiene en el primer fallo, se ejecuta una sola vez.
  • Añadido — recurso Secret y /v1/secrets (GET, POST, PUT upsert por key, GET/PATCH/DELETE por id). Son los valores que un paso de workflow referencia como ${{secrets.KEY}}; el valor es de solo escritura y ningún endpoint lo devuelve. Scope inbox/secrets (+ write).
  • Añadido — recurso WorkflowRun y /v1/workflow-runs (GET lista, GET por id con todos los pasos). Solo lectura. Scope inbox/workflow_runs. Los contadores se agrupan en summary: { total, succeeded, error }, y la llamada HTTP de cada paso en request: {} / response: {}.
  • Añadido — herramientas MCP secrets_list, secrets_get, secrets_create, secrets_upsert, secrets_update, secrets_delete, workflow_runs_list, workflow_runs_get, y los servidores stdio correspondientes.
  • Añadido — eventos de webhook workflow.run.succeeded, workflow.run.failed, workflow_run.db.created, workflow_run.db.updated, workflow_run.status_changed.
  • Cambiado — los payloads de email.agent.processed ahora también llevan workflow_run_id (null cuando el agente no devolvió workflow). Aditivo: quienes ya lo consumen no se ven afectados.

Todo aditivo — nada existente cambió de forma o comportamiento.

2026-09-08​

  • Añadido — los payloads de webhook email.* ahora traen data.email.download_url: un enlace listo para usar hacia el .eml original, válido por 30 minutos, que quien recibe el webhook puede seguir sin certificado mTLS ni JWT de la API. Ver Descargando el .eml desde un webhook. Cambio aditivo — quienes ya consumen data.email no se ven afectados.