Aller au contenu principal
MaFactureOK

Automatiser vos vérifications de clients avec Make

Avant que votre scénario Make ne crée une facture dans Tiime ou votre logiciel, insérez un nœud qui vérifie le client : existe-t-il, est-il actif, sa TVA est-elle valide ? Le nœud générique « HTTP » de Make suffit : une application ne s’installe pas : installer, aucune clé à créer.

API publique

Un scénario Make vu en diagramme : un déclencheur webhook, une suite de modules reliés, puis des routeurs qui aiguillent vers un agenda ou un email selon le cas.
Ce à quoi ressemble un scénario Make : des modules enchaînés et des routeurs qui aiguillent. Le nôtre suit la même logique : une source, le module HTTP qui vérifie, un routeur par signal, puis vos propres modules.

  1. Le module « HTTP > Make a request »

    • Authentication type : No authentication (la clé passe par un en-tête, ci-dessous)
    • URL : https://mafactureok.com/api/public/v1/verifier-tiers
    • Method : POST
    • Headers : un en-tête dont le nom est Authorization et la valeur Bearer suivi d'un espace et de votre clé (reçue par email depuis la page API). Le nom de l'en-tête est bien Authorization, pas Bearer.
    • Body content type : application/json
    • Body input method : JSON string
    • Parse response : Yes (Make transforme la réponse JSON en champs mappables, disponibles après une première exécution)

    Body content :

    { "identifiants": ["{{SIREN du client}}"] }

    Mappez la colonne SIREN de votre source à la place de l'élément entre accolades.

    Module HTTP de Make : Authentication type sur No authentication, URL de l'endpoint verifier-tiers, Method POST, un en-tête nommé Authorization dont la valeur commence par Bearer suivi de la clé.
    Le haut du module HTTP : l'URL, la méthode POST et l'en-tête Authorization avec la clé (masquée ici).
    Module HTTP de Make : Body input method réglé sur JSON string, Body content contenant l'objet identifiants avec le SIREN du client mappé, Parse response sur Yes.
    Le bas du module HTTP : le corps de la requête avec le SIREN mappé, et l'analyse de la réponse activée.

  2. Le routeur, piloté par le signal

    • Ajoutez un Router après le module HTTP, avec un filtre par branche sur resultats[].signal :
    • signal = ok : module suivant, créer la facture dans votre logiciel (Tiime, etc.)
    • signal = indetermine : module Sleep (quelques minutes) puis nouvel appel ; un service officiel n'a pas répondu, c'est transitoire
    • signal = alerte ou avertissement : notification humaine (email, Slack, ligne dans un Sheet) ; une donnée est en cause, réessayer ne la changera pas

  3. La correction, en nœud distinct et optionnel

    • La vérification ne modifie jamais rien : elle qualifie.
    • Si vous voulez corriger (reprendre la raison sociale officielle, le SIRET du siège actif proposé), faites-le dans un module séparé que vous branchez explicitement sur la branche alerte/avertissement.
    • Après correction, repassez par la vérification : si le signal devient ok, la branche facturation reprend.

  4. Le dernier maillon vous appartient

    • Notification, ticket, stockage des anomalies : branchez vos propres modules.
    • Nous nous arrêtons à « donnée fiable ou anomalie qualifiée » ; votre scénario décide de la suite.

Limites de la bêta : 200 identifiants vérifiés par jour et par clé, 25 par appel ; au-delà, l’API répond 429 avec un délai Retry-After à respecter dans votre module d’attente. Seuls les numéros SIREN/SIRET transitent : jamais vos factures, noms de clients ou montants.

Le contrat complet (réponse, signaux, codes) est décrit sur la page API publique. Pour vérifier un portefeuille ponctuellement sans automatisation, l’import de fichier de la page Vérifier un client avant de facturer fait la même chose dans le navigateur.