RRelancia
Référence

Référence

Spécification exhaustive du format JSON d'une relance Relancia. Source de vérité pour les outils qui doivent générer des plans sans erreur.

Cette section décrit, sans rien omettre, la structure JSON d'une relance Relancia. Chaque bloc, chaque déclencheur, chaque vérification, chaque message, chaque action est documenté avec sa forme JSON exacte, ses paramètres et ses contraintes.

L'objectif est de servir de référence pour tout outil — y compris un assistant IA — qui doit produire un JSON de relance correct, sans rien inventer.

Sommaire

PageContenu
Schéma généralFormat racine, règles communes, conventions
DéclencheursLes 5 points de départ possibles d'une relance
VérificationsLes 4 conditions qui aiguillent le flux
MessagesLes 3 blocs qui envoient un message au client
ActionsLes 5 blocs qui exécutent une opération interne ou externe
VariablesLes variables insérables dans les messages
LimitesLes bornes numériques et règles de validation
Exemple completUne relance prête à coller dans l'éditeur

Schéma de la racine

Toute relance est un objet JSON conforme au schéma suivant :

{
  "name": "Rappel WhatsApp après appel manqué",
  "description": "Description optionnelle de la relance.",
  "status": "draft",
  "trigger_type": "missed_call",
  "nodes": [ /* tableau de blocs */ ],
  "edges": [ /* tableau de liaisons */ ]
}
ChampTypeObligatoireValeurs possibles
nametexteoui1 à 160 caractères
descriptiontextenon0 à 500 caractères
statustexteouidraft, active, paused
trigger_typetexteouimissed_call, shopify, prestashop, csv_import, webhook
nodestableauouiau moins 1 bloc, au plus 500
edgestableaunon0 à 1200 liaisons

Schéma d'un bloc (nodes[i])

{
  "id": "identifiant-unique",
  "type": "trigger",
  "position": { "x": 80, "y": 160 },
  "data": {
    "label": "Titre affiché",
    "subtitle": "Sous-titre",
    "channel": "appel",
    "description": "Description interne du bloc",
    "parameters": {
      "cle1": "valeur1",
      "cle2": "valeur2"
    }
  }
}
ChampTypeObligatoireContraintes
idtexteouiunique dans le plan, 1 à 120 caractères
typetexteouiexactement trigger, condition, message ou action
position.xnombreouivaleur numérique finie
position.ynombreouivaleur numérique finie
data.labeltexteoui1 à 160 caractères
data.subtitletextenon0 à 160 caractères
data.channeltexteoui1 à 80 caractères, voir liste des canaux
data.descriptiontextenon0 à 500 caractères
data.parametersobjetnonclés et valeurs en texte, jusqu'à 24 entrées

Les canaux observés dans les blocs standard sont : appel, qualification, whatsapp, email, commercial, vérification, ai, http, csv, shopify, prestashop, webhook, lien, crm, départ.

Schéma d'une liaison (edges[i])

{
  "id": "edge-1",
  "source": "id-du-bloc-source",
  "target": "id-du-bloc-cible",
  "label": "Condition d'activation",
  "type": "smoothstep",
  "animated": true
}
ChampTypeObligatoireContraintes
idtexteouiunique dans le plan, défaut edge-{index}-{source}-{target}
sourcetexteouidoit référencer un nodes[i].id existant
targettexteouidoit référencer un nodes[i].id existant
labeltextenon0 à 120 caractères, affiché sur la flèche
typetextenondéfaut smoothstep, autres valeurs autorisées selon la bibliothèque de rendu
animatedbooléennondéfaut true

Conventions

  • Les id de blocs et de liaisons doivent être uniques au sein du plan. Un doublon est rejeté.
  • Les id courts en kebab-case sont recommandés (trigger-missed-call, send-whatsapp-recall).
  • Toutes les valeurs de parameters sont des chaînes de texte. Pas de booléen, pas de nombre : convertir en texte avant l'écriture.
  • Les position.x et position.y sont des nombres, pas des chaînes.
  • Pour une question de lisibilité, séparez les blocs déclencheurs à gauche (x ≈ 80) et les blocs d'action à droite (x ≥ 360), avec un pas horizontal de 280 à 320 px.

Format attendu pour parameters

L'objet parameters est un simple dictionnaire clé/valeur. Toutes les valeurs sont des chaînes de texte. Pour une action de type http_request, les valeurs headers_json et body_json doivent être des chaînes contenant du JSON valide (par exemple "{\"Authorization\": \"Bearer VOTRE_TOKEN\"}").

Ce que l'éditeur accepte

L'éditeur accepte un JSON conforme au schéma ci-dessus. Tout JSON collé est validé avant insertion. Si une règle n'est pas respectée, l'éditeur affiche la liste des chemins fautifs avec la raison. La relance n'est créée que lorsque toutes les règles passent.

Pour la liste détaillée des règles et des bornes, voir Limites.

On this page