Types de modèles

Trois familles, un seul appel de génération

Chaque modèle porte une category : custom, fillable_form, ou workflow. Une fois publiés, les trois sont listés par GET /api/v1/templates, lus par GET /api/v1/templates/:id, et générés avec la même forme de payload POST /api/v1/document_requests. Les endpoints d'index et de détail ne filtrent jamais par catégorie. Ce qui diffère nettement, c'est la façon dont chacune est créée, et la part de cette création que l'API classique expose.

Custom (category: "custom")

Un modèle HTML libre : vous contrôlez chaque élément de la mise en page, et vous définissez vous-même chaque variable.

• À quoi ça sert : tout document que vous voulez concevoir vous-même. La mise en page n'est contrainte par aucun fichier existant.
• Création : dans l'éditeur HTML en ligne du dashboard, ou via les champs content et variables_attributes de l'API.
• Via l'API : CRUD complet, publication/dépublication, et CRUD complet sur ses variables. C'est la seule catégorie que l'API classique peut créer.

Voir API Modèles et API Variables.

Formulaire PDF (category: "fillable_form")

Un modèle adossé à un PDF téléversé qui porte déjà des champs de formulaire (widgets AcroForm) : champs de texte, cases à cocher, groupes de boutons radio, listes déroulantes.

• À quoi ça sert : réutiliser une mise en page PDF existante (un formulaire réglementaire, un document qui a déjà son design final) plutôt que de la reconstruire en HTML.
• Création : en téléversant le PDF depuis le dashboard. Doclift extrait chaque champ de formulaire en une variable : title est le nom technique du champ, description est le libellé du champ (ou son nom technique à défaut), field_type et allowed_values sont déduits du widget PDF, et seed_value provient de la valeur par défaut du champ, le cas échéant. Retéléverser une nouvelle version du PDF resynchronise les variables : les nouveaux champs deviennent de nouvelles variables, et les champs qui ne sont plus présents sont détruits. Depuis le dashboard, vous ne pouvez modifier que la description et le seed_value d'une variable ; son title et son field_type reflètent toujours le PDF et ne peuvent être renommés ni retypés à la main.
• Via l'API : lecture seule. GET /api/v1/templates et /:id le renvoient une fois publié, avec ses variables auto-détectées incluses dans la réponse de détail. POST /api/v1/document_requests génère à partir de lui exactement comme un modèle custom. Rien d'autre : aucun endpoint de création, mise à jour, suppression, publication/dépublication ou variables ne l'accepte.

Voir Formulaires PDF pour la référence complète de génération et de mappage des variables.

Workflow (category: "workflow")

Une arborescence de sections (groupes imbriqués et blocs de contenu, chacun avec sa propre condition) plutôt qu'un seul bloc HTML. Il a sa propre API, montée entièrement sous /api/v1/workflows/* : modèles, sections, variables, thème et publication y sont des ressources séparées. Les endpoints d'écriture classiques de /api/v1/templates ne touchent jamais à un workflow.

• À quoi ça sert : les documents assemblés à partir de nombreuses parties incluses sous condition (contrats longs, documents à scénarios multiples) où vous avez besoin d'une structure que l'éditeur HTML en un seul bloc ne vous donne pas.
• Création : entièrement via l'API workflow (ou le constructeur de workflow du dashboard) ; l'API classique ne peut ni créer, ni modifier, ni supprimer un modèle workflow.
• Via l'API classique : le même accès en lecture seule et en génération seule que fillable_form. GET /api/v1/templates et /:id le listent et l'affichent une fois publié, et POST /api/v1/document_requests génère à partir de lui.