1.
Criar o template base (POST /templates): registra nome, processador, escopo e descrição, e retorna uma URL assinada e temporária para o envio do arquivo .docx.
2.
Enviar o arquivo .docx na URL assinada retornada na etapa anterior.
3.
Definir os campos (PUT /templates/{id}/fields): os campos enviados na etapa 1 não são persistidos como configuração definitiva — esta chamada é sempre necessária para que os campos realmente passem a valer.
4.
Configurar regras condicionais, se necessário (PUT /templates/{id}/fields/rules) — opcional, usada para exibir, ocultar ou tornar campos obrigatórios/opcionais com base no valor de outros campos.
5.
Ativar o template (PUT /templates/{id}/activate): etapa final, obrigatória para que o template fique disponível para geração de documentos. Também precisa ser repetida sempre que os campos ou as regras condicionais forem alterados depois da ativação inicial, já que ambas as operações desativam o template como efeito colateral.
Campo do formulário inicial do flow: path fixo start-form e reference igual ao identificador do campo.
Campo de uma fase: path no formato phase-field.<identificador-da-fase> e reference no formato <identificador-da-fase>:<identificador-do-campo>.
Campo do parecer técnico: path fixo opinion-field e reference igual ao identificador do campo.
Campos nativos (dados básicos do cliente, aprovações, motor de crédito, entre outros): apenas um path fixo (por exemplo basic-data.name ou credit-engine.score), sem reference.
Cada fase admite no máximo uma configuração de geração automática de documento. Criar uma nova quando já existe uma retorna erro informando que já existe uma configuração para aquele flow e fase (a mensagem inclui o identificador da configuração existente). Para editar uma configuração já existente, o caminho recomendado é remover a atual e criar uma nova — embora a chamada de atualização direta também esteja disponível para o caso de apenas repontar o template vinculado.
Enviar um novo arquivo para um template existente não o atualiza no mesmo lugar — o resultado é um novo template, com identificador novo. O original permanece intacto (cards que já geraram documentos a partir dele continuam referenciando o identificador antigo), mas qualquer configuração de geração automática, configuração de conversa ou trigger que apontava para o identificador antigo precisa ser atualizada manualmente.
Definir os campos ou as regras condicionais de um template desativa o template como efeito colateral — é sempre necessário ativá-lo novamente em seguida.
Se um campo referenciar uma seção (section) que não foi declarada na criação do template, a definição de campos falha com erro informando que a seção não foi encontrada.
O payload de campos aceita apenas um conjunto específico de propriedades (key, title, type, path, reference, required, options, section, uiComponent, children, rules) — propriedades como active, editable, category, index, id, createdAt, updatedAt e sectionKey são rejeitadas.
Um template é sempre específico de um flow: reutilizar o identificador de um template criado em outro flow retorna erro de recurso não encontrado.
Após a criação de um template, pode levar alguns instantes até que ele apareça na listagem — a indexação é assíncrona. Chamadas subsequentes que dependam do template recém-criado podem falhar nesse intervalo; recomendamos uma nova tentativa após alguns segundos.
A remoção de um template é irreversível: cards que já geraram documentos a partir dele ficam com o link de download quebrado.
Na geração do documento (POST .../generate), os campos de clients[] e generalSections[] nunca incluem a propriedade id — usam a chave (key) declarada no template, prefixada pelo grupo pai quando aplicável (por exemplo fiadores.nome).