> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.goodflag.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.goodflag.com/_mcp/server.

# Introduction

> Périmètre de l'API, le tenant, ce que le client gère et ce que Goodflag fournit

# Intégration de l'API Workflow Manager de Goodflag Signature & votre périmètre

## Où se situe cette documentation

**Goodflag Signature** est une plateforme de signature électronique. Elle comprend
notamment :

* le **Workflow Manager** — l'**API** qui permet de provisionner des **parapheurs** de
  signature électronique. **C'est l'objet de cette documentation.**
* le **Request Manager** — une API qui permet de provisionner des **transactions** de
  signature électronique (*hors périmètre de cette documentation*) ;
* un **Portail** Web, avec lequel les utilisateurs d'une organisation créent des parapheurs
  (et tout ce qui va avec), et qui **s'appuie lui-même sur l'API du Workflow Manager** ;
* des **services de confiance** opérant en coulisses : l'**Evidence Manager**, le dispositif
  de création de signature à distance (**SAM + HSM**), et les fournisseurs d'**identité**, d'envoi d'**email** et de **SMS**.

Tout ce qui suit décrit donc **l'API du Workflow Manager**.

## L'API, moteur de signature de votre application métier

L'API Goodflag Signature - Workflow Manager est celle qui fait fonctionner le **Portail
Goodflag Signature** lui-même. En l'exploitant directement, **votre application métier gère
l'essentiel de bout en bout** — création des parapheurs, chargement des documents,
invitations, suivi, récupération des preuves — **sans avoir à exposer le Portail à vos
utilisateurs**.

Vous pouvez utiliser le Portail pour configurer les différentes composantes de votre tenant si vous le souhaitez, mais tout ce que vous faites par le biais du Portail peut être effectué avec l'API. En revanche, certaines opérations ne sont accessibles **que par l'API** : c'est le cas, par exemple, de la personnalisation des **messages** envoyés aux destinataires (invitations à signer, relances…).

**Avertissement** : ce document ne vise pas à être une documentation exhaustive de l'API car certaines fonctions ne sont pas utiles dans un contexte d'intégration avec une application ou un logiciel métier. C'est le cas par exemple des modèles ou bien des possibilités de personnalisation graphique du portail de votre tenant.

## Votre tenant

À la souscription, Goodflag met à votre disposition **votre tenant** préconfiguré, ainsi que les
**pages de consentement** adaptées à vos besoins de signature. Le Workflow Manager est
multi-tenants, mais vous travaillez au sein de votre tenant unique qui vous a été alloué.

**Ce que vous gérez vous-même** (dans votre tenant, via l'API) :

* vos **utilisateurs** et vos **groupes** ;
* vos **profils de signature**, vos **dispositions de métadonnées**, vos **modèles** de
  parapheur, vos **webhooks** ;
* vos **parapheurs** : création des **étapes**, **chargement des documents**, positionnement
  des **champs de signature**, **lancement du parapheur**, suivi de leur **avancement** ;
* la récupération des **documents signés** et des **fichiers de preuve** ;
* vos **paramètres**, y compris la personnalisation des **messages**.

**Ce que Goodflag met à votre disposition** :

* **votre tenant** lui-même ;
* des **profils de signature prédéfinis** qui définissent à la fois le type de document
  autorisé (par exemple PDF), le format de signature (par exemple PAdES) et le look de la
  signature visible, le cas échéant — voir la fondation [*Profils de signature*](/wm/api-reference/concepts/profils-de-signature) ;
* des **pages de consentement** : chacune encapsule le **niveau de signature** et la
  **méthode d'authentification** appliqués à une étape. Vous les
  référencez par leur identifiant (`consentPageId`) — voir la fondation [*Pages de consentement*](/wm/api-reference/concepts/pages-de-consentement).

> **À noter** — Les **modèles** (templates) sont surtout utiles pour organiser et gérer la
> cohérence de la création des parapheurs au sein de votre organisation ; mais lorsque
> votre application pilote l'API directement, ils sont rarement nécessaires : votre
> application construit chaque parapheur à la volée avec le paramétrage précis que vous
> souhaitez.

## Personnalisation & marque

Les objets fournis en base — **pages de consentement**, **profils de signature**,
**messages**, et jusqu'aux **paramètres du tenant** lui-même — restent **personnalisables**
par vos soins. Vous adaptez ainsi le tenant dans son **fonctionnement** comme dans son
**apparence** :

* **Comportement** — par exemple la **taille limite** des fichiers à signer ou le
  **nombre de pièces jointes** autorisées.
* **Marque** — **logo** et **couleurs** à votre image. Au niveau du **tenant**, vous
  définissez votre logo et vos couleurs (primaire, secondaire, foncée) ; au niveau de
  chaque **page de consentement**, le logo et des options d'affichage propres à l'écran vu
  par le signataire (par exemple **masquer les boutons de téléchargement**). Les
  **messages** (invitations à signer, relances) portent également votre marque, et les
  **profils de signature** personnalisent les **cartouches (pavés) de signature**.

C'est un atout d'intégration majeur : votre application exploite l'API en coulisses,
tandis que l'expérience de signature reste **à votre marque**, de bout en bout.

## Authentification, en bref

Les appels à l'API s'authentifient par un **jeton d'API** (`Bearer act_<id>.<secret>`),
créé depuis un compte disposant du rôle **`developer`**. Ce jeton d'API est un secret : il
doit être conservé et utilisé **côté backend** de votre application, jamais exposé au
client. Le détail (création, portée, bonnes pratiques) fait l'objet de la fondation
*Authentification & jetons d'API*.