> ## Documentation Index > Fetch the complete documentation index at: https://developers.nuvia.ai/llms.txt > Use this file to discover all available pages before exploring further. # Actualizar conocimiento o archivo multimedia > Actualiza el nombre y/o la descripción de un conocimiento o archivo multimedia ## OpenAPI ````yaml /es/openapi.json patch /v1/knowledge/{id} openapi: 3.0.0 info: title: Nuvia API - Empresa description: Documentación de la API para empresas version: '1.0' contact: {} servers: - url: https://api.nuvia.ai security: [] tags: - name: messages x-group: Mensagens - name: contacts x-group: Contatos - name: campaigns x-group: Campanhas - name: tables x-group: Tabelas e Listas - name: agents x-group: Agentes - name: conversations x-group: Conversas - name: inboxes x-group: Caixas de Entrada - name: knowledge x-group: Base de Conhecimento - name: Webhooks x-group: Webhooks - name: campaign-enrollments x-group: Inscrições em Campanha - name: custom-fields x-group: Campos Customizados paths: /v1/knowledge/{id}: patch: tags: - knowledge summary: Actualizar conocimiento o archivo multimedia description: >- Actualiza el nombre y/o la descripción de un conocimiento o archivo multimedia operationId: KnowledgeController_update parameters: - name: x-company-id in: header description: >- Identificador de la empresa objetivo. Obligatorio solo para API keys globales (type=global). Se ignora para API keys de empresa y usuarios humanos. required: false schema: type: string - name: id required: true in: path description: ID del conocimiento/medio schema: type: string responses: '200': description: '' content: application/json: schema: $ref: '#/components/schemas/KnowledgeEntity' security: - JWT-auth: [] components: schemas: KnowledgeEntity: type: object properties: _id: $ref: '#/components/schemas/ObjectId' name: type: string description: type: string type: enum: - KNOWLEDGE - MEDIA type: string s3_key: type: string description: >- Clave del objeto en S3. Fuente de la verdad para generar la URL firmada. file_url: type: string deprecated: true file_type: enum: - PDF - DOCX - AUTCL - IMAGE - VIDEO - AUDIO - DOCUMENT type: string content: type: string status: enum: - PROCESSING - READY - ERROR type: string meta: type: object company: $ref: '#/components/schemas/CompanyEntity' createdAt: format: date-time type: string updatedAt: format: date-time type: string required: - _id - name - type - file_type - company ObjectId: type: object properties: {} CompanyEntity: type: object properties: _id: $ref: '#/components/schemas/ObjectId' name: type: string channels: type: array items: type: string enum: - WAP_AUTO_CLOSER - WEB_V2 - EVOLUTION_API - LINKEDIN - EMAIL agent_flows: type: array items: $ref: '#/components/schemas/AgentFlowEntity' description: type: string description: >- Opcional desde ISSUE-6330: las empresas creadas por self-service nacen sin descripción (las legadas anteriores a 2025-09-07 tampoco tienen el campo). La obligatoriedad se mantiene en las capas de ENTRADA del backoffice (DTOs Zod de create-company/create-internal-company y formularios) — intactas. domains: description: >- Dominios de correo que resuelven a ESTA company en el signup self-service (ISSUE-6330): 1 dominio → como máximo 1 company (índice único parcial más abajo). Solo el flujo self-service escribe; las companies antiguas del backoffice quedan SIN el campo (sin backfill — entran en la resolución por inferencia vía el correo de los users). Canonicalizado en lowercase/trim en el schema (molde de signup_leads.domain). `default: undefined` para que el campo nazca AUSENTE (un array default [] entraría en la semántica del índice parcial y cambiaría los docs del backoffice sin necesidad). type: array items: type: string site: type: string description: >- [ISSUE-6438] Sitio informado en el wizard. INFORMATIVO — no participa de la resolución por dominio y no tiene índice único. Existe debido al workspace de correo personal (SIGNUP_ALLOW_PERSONAL_EMAILS): allí el dominio no se puede derivar del correo, así que el usuario lo escribe. Colocarlo en `domains` reclamaría el dominio globalmente (el índice es único) y permitiría que alguien con @gmail registre "google.com" — por eso es un campo separado, con `domains: []`. general_config: type: object status: enum: - ACTIVE - INACTIVE - DELETED type: string agent_builder_mcp_enabled: type: boolean description: >- Habilita las tools del agent builder en el `/mcp` del cliente para ESTA empresa. Predeterminado `true`: el builder es GA — toda empresa lo tiene, salvo opt-OUT explícito (`false`). Es el interruptor por empresa de EXCLUSIÓN (ej.: desactivar a un cliente que hizo un desastre), no de inclusión. El gate de AUTORÍA sigue siendo el role (COMPANY_ADMIN); un usuario común solo lee/simula. Las empresas creadas antes del GA se activaron vía backfill (scripts/backfill-agent-builder-mcp-flag.ts). client_mcp_servers_enabled: type: boolean description: >- Habilita el feature de servidores MCP del cliente (SDD "MCP del cliente en las tools del agente", §8 rollout) para ESTA empresa. Ausente/false = flag OFF: las rutas de `/mcp-servers` responden 403 (excepto el callback OAuth, que es público) y las tools MCP ya materializadas quedan INERTES en el runtime (desaparecen del array del agente, sin borrar nada de la base de datos). Predeterminado deliberado `false`: es rollout gradual, no GA como `agent_builder_mcp_enabled`. auto_join_enabled: type: boolean description: >- [ISSUE-6432] Ingreso automático por dominio. Ausente/false = DESACTIVADO (valor predeterminado deliberado: activarlo es decisión del admin, no un estado inicial). Activado, quien se registra con un correo del dominio de esta company ingresa directamente como miembro, en lugar de generar una solicitud de acceso. Afecta SOLO a esta company: un dominio con varias companies sigue dejando que la persona elija, y entre las elegidas solo la que lo activó permite el ingreso directo. subscription: type: object description: >- Suscripción/trial (ISSUE-6334). Valor predeterminado `{status:'active'}` — la company creada por el backoffice nace ACTIVA (decisión de producto); el flujo self-service (ProvisionCompanyByDomainService) lo sobrescribe con `trialing` + fechas. Un documento legado sin el campo = activo (ver resolveSubscriptionStatus + script de backfill). onboarding: type: object description: >- [ISSUE-6438] Estado del wizard de onboarding. `default: undefined` para que el campo nazca AUSENTE (misma técnica que `domains`): la company del backoffice no recibe el subdocumento y se resuelve como completada en `resolveOnboardingStatus`. attribution: type: object description: >- Campaña que trajo esta company (`utm_*` de quien la creó). ── Por qué aquí, si el UTM ya vive en `signup_leads` ── Allí la clave es el CORREO, y el vínculo llega solo hasta el user. Cruzar la campaña con el trial, la activación o el ingreso exigía un join manual por correo del primer usuario — que se rompe en cuanto la persona cambia de correo o se va. Se copia en la CREACIÓN, y solo entonces. No hay backfill: una company que nació antes de esto queda sin el campo, y su ausencia significa "no lo sabemos", no "orgánico". `default: undefined` para nacer AUSENTE (misma técnica que `onboarding`): la company del backoffice no pasa por el flujo self-service y no debe recibir un subdocumento vacío. required: - _id - name - channels - agent_flows - description - status AgentFlowEntity: type: object properties: _id: $ref: '#/components/schemas/ObjectId' name: type: string url: type: string specialist_url: type: string type: enum: - N8N - API - INTERNAL type: string required: - _id - name - url - specialist_url - type securitySchemes: JWT-auth: scheme: bearer bearerFormat: JWT type: http description: Token JWT de autenticação ````