> ## 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. # Criar conhecimento em markdown > Cria um item do tipo AUTCL: conteúdo markdown editável pela própria API, sem upload de arquivo. O texto vira chunks + embeddings em background — o item nasce `PROCESSING` e vai para `READY`. A cada edição os embeddings são regerados. ## OpenAPI ````yaml https://api.nuvia.ai/api/docs/user-json post /v1/knowledge/autcl openapi: 3.0.0 info: title: Nuvia API - Empresa description: Documentação da 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 paths: /v1/knowledge/autcl: post: tags: - knowledge summary: Criar conhecimento em markdown description: >- Cria um item do tipo AUTCL: conteúdo markdown editável pela própria API, sem upload de arquivo. O texto vira chunks + embeddings em background — o item nasce `PROCESSING` e vai para `READY`. A cada edição os embeddings são regerados. operationId: KnowledgeController_createAutcl parameters: - name: x-company-id in: header description: >- Identificador da empresa-alvo. Obrigatório apenas para API Keys globais (type=global). Ignorado para API Keys de empresa e usuários humanos. required: false schema: type: string requestBody: required: true content: application/json: schema: type: object required: - name - content properties: name: type: string description: Nome do conhecimento description: type: string description: Descrição opcional content: type: string description: Conteúdo em formato markdown responses: '201': 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: Chave do objeto no S3. Fonte da verdade para gerar URL assinada. 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: companies criadas pelo self-service nascem sem descrição (as legadas pré-2025-09-07 também não têm o campo). A obrigatoriedade continua nas camadas de ENTRADA do backoffice (DTOs Zod de create-company/create-internal-company e forms) — intocadas. domains: description: >- Domínios de e-mail que resolvem para ESTA company no signup self-service (ISSUE-6330): 1 domínio → no máximo 1 company (índice único parcial abaixo). Só o fluxo self-service escreve; companies legadas do backoffice ficam SEM o campo (sem backfill — entram na resolução por inferência via e-mail dos users). Canonicalizado lowercase/trim no schema (molde de signup_leads.domain). `default: undefined` para o campo nascer AUSENTE (array default [] entraria na semântica do índice parcial e mudaria docs do backoffice sem necessidade). type: array items: type: string site: type: string description: >- [ISSUE-6438] Site informado no wizard. INFORMATIVO — não participa da resolução por domínio e não tem índice único. Existe por causa do workspace de e-mail pessoal (SIGNUP_ALLOW_PERSONAL_EMAILS): ali o domínio não pode ser derivado do e-mail, então o usuário digita. Colocá-lo em `domains` reivindicaria o domínio globalmente (o índice é único) e deixaria alguém com @gmail registrar "google.com" — por isso campo separado, com `domains: []`. general_config: type: object status: enum: - ACTIVE - DELETED type: string agent_builder_mcp_enabled: type: boolean description: >- Libera as tools do agent builder no `/mcp` do cliente para ESTA empresa. Default `true`: o builder é GA — toda empresa tem, salvo opt-OUT explícito (`false`). Vira o interruptor por-empresa de EXCLUSÃO (ex.: desligar um cliente que fez bagunça), não de inclusão. O gate de AUTORIA continua sendo o role (COMPANY_ADMIN); usuário comum só lê/simula. Empresas criadas antes do GA foram ligadas via backfill (scripts/backfill-agent-builder-mcp-flag.ts). auto_join_enabled: type: boolean description: >- [ISSUE-6432] Entrada automática por domínio. Ausente/false = DESLIGADO (default deliberado: ligar é decisão do admin, não estado inicial). Ligado, quem faz signup com e-mail do domínio desta company entra direto como membro, em vez de gerar pedido de acesso. Afeta SÓ esta company: domínio com várias companies segue com a pessoa escolhendo, e entre as escolhidas só a que ligou entra direto. subscription: type: object description: |- Assinatura/trial (ISSUE-6334). Default `{status:'active'}` — company criada pelo backoffice nasce ATIVA (decisão de produto); o fluxo self-service (ProvisionCompanyByDomainService) sobrescreve com `trialing` + datas. Doc legado sem o campo = ativo (ver resolveSubscriptionStatus + script de backfill). onboarding: type: object description: >- [ISSUE-6438] Estado do wizard de onboarding. `default: undefined` para o campo nascer AUSENTE (mesma técnica de `domains`): company do backoffice não ganha o subdocumento e resolve como concluída em `resolveOnboardingStatus`. attribution: type: object description: >- Campanha que trouxe esta company (`utm_*` de quem criou). ── Por que aqui, se o UTM já vive em `signup_leads` ── Lá a chave é o E-MAIL, e o vínculo vai só até o user. Cruzar campanha com trial, ativação ou receita exigia um join manual por e-mail do primeiro usuário — que quebra assim que a pessoa troca de e-mail ou sai. Copiado na CRIAÇÃO, e só. Não há backfill: company que nasceu antes disto fica sem o campo, e ausente significa "não sabemos", não "orgânico". `default: undefined` para nascer AUSENTE (mesma técnica do `onboarding`): company do backoffice não passa pelo fluxo self-service e não deve ganhar um subdocumento vazio. 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 ````