Remplacer un participant par un nouveau contact

curl -X POST "https://staging-api.docage.com/Transactions/CreateFullTransaction" \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9…" \
  -F "TemplateId=aaaaaaaa-0000-4000-8000-000000000001" \
  -F 'Client={"FirstName":"Camille","LastName":"Martin","Email":"camille.martin@example.com","Mobile":"+33600000001","Country":"FR"}'

Sous l'identifiant convivial du participant (Client), un contact en JSON : ses propriétés sont celles d'un contact (FirstName, LastName, Email, Mobile, Phone, Address1, ZipCode, City, Country, Job…). Le contact est créé avec le parcours, et le participant prend ses coordonnées.

Ce qui est vérifié, et quand

Rien n'est vérifié à la création du contact : c'est l'envoi du parcours qui exige de chaque participant un email valide, un prénom et un nom (« Client : n'a pas un prénom valide »…), et un mobile si le code de signature part par SMS. Un envoi refusé laisse le parcours en brouillon, et le contact créé.

Les pièges

• Si le participant du modèle désigne déjà un contact, c'est ce contact qui est modifié par le JSON — même sans Id —, et il faut avoir le droit de le modifier. Le JSON ne crée un contact que pour un participant à définir. Pour une autre personne, créez d'abord son contact (POST https://staging-api.docage.com/Contacts), puis désignez-le par son identifiant : voir Remplacer un participant par un contact existant.
• Aucun contrôle de doublon n'empêche cette création : cherchez d'abord la personne par son email, et désignez son contact s'il existe.
• Country est un code de pays ISO à deux lettres (FR) ; un libellé (« FRANCE ») est gardé tel quel, sans être reconnu.
• Écrivez un numéro au format international E.164 (+33600000001) : il est enregistré ainsi.