Connecter Swimlane à Make

Make (anciennement Integromat) se connecte à Swimlane comme à n'importe quel service web : Swimlane pousse les événements contact vers un webhook Make, et Make appelle l'API publique de Swimlane avec un module HTTP. Il n'y a pas d'application Swimlane à installer dans Make.

Avant de commencer

Un compte Make.
Un token API Swimlane si votre scénario doit lire ou écrire des données Swimlane (voir Créer un token API et faire votre première requête).

Recevoir les événements Swimlane dans un scénario

Dans Make, créez un scénario et ajoutez le déclencheur Custom webhook de l'application Webhooks.
Créez un nouveau webhook, nommez-le et copiez son adresse.
Dans Swimlane, ouvrez Paramètres → Webhooks, cliquez sur Ajouter un webhook, collez l'adresse, cochez les événements voulus et cliquez sur Créer le webhook (voir Configurer des webhooks).
Swimlane envoie aussitôt une requête de test. Son corps ne contient que event = test et un message : Make n'y voit donc pas les champs d'un contact.
Pour apprendre à Make la vraie structure, demandez au module webhook de redéterminer la structure des données, puis faites une vraie modification dans Swimlane, par exemple écrire une note sur un contact. L'événement arrive en une minute environ.
Make connaît désormais event, timestamp et data (uuid, firstName, lastName, email, linkedinId, et changes pour les mises à jour). Utilisez-les dans les modules suivants.
Ajoutez un filtre juste après le déclencheur pour ne continuer que si event est différent de test.
Activez le scénario.

Appeler l'API Swimlane depuis Make

Ajoutez le module Make a request de l'application HTTP.
URL : par exemple https://api.getswimlane.com/v1/contacts/{{data.uuid}}, en reprenant l'uuid du webhook.
Méthode : GET.
Ajoutez un en-tête nommé Authorization avec la valeur Bearer wpa_votre_token.
Activez l'analyse de la réponse pour pouvoir utiliser les champs JSON.

La réponse ajoute le titre, la localisation, companyUuids, tagIds, listUuids et pipelineStageUuid. Appelez GET /v1/companies/<uuid> pour le nom de l'entreprise.

Recette : traiter les contacts tagués à intervalle régulier

Poser un tag n'envoie pas de webhook. Pour transmettre les contacts qu'un commercial a tagués, par exemple « À envoyer au CRM » :

Démarrez le scénario par un module HTTP Make a request : GET https://api.getswimlane.com/v1/contacts?tag_id=12&per_page=100 (retrouvez les identifiants de tags avec GET /v1/tags).
Parcourez data et envoyez chaque contact vers votre CRM ou votre outil de prospection.
Remplacez le tag avec POST https://api.getswimlane.com/v1/contacts/<uuid>/tags et un corps JSON comme {"tagIds": [18]}.
Planifiez le scénario, par exemple toutes les 15 minutes.

L'appel sur les tags remplace tous les tags du contact. Construisez la nouvelle liste à partir de ses tagIds actuels : retirez l'identifiant « À envoyer au CRM », ajoutez celui de « Envoyé », gardez les autres.

Bon à savoir

Limite de débit : 100 requêtes API par minute par utilisateur Swimlane. De grosses itérations peuvent provoquer des 429 : ralentissez-les ou traitez moins de contacts par exécution.
Le token agit sur l'organisation que vous avez utilisée en dernier dans l'application Swimlane.
Doublons : les webhooks de chaque membre reçoivent les événements de toute l'organisation. Créez le webhook depuis un seul compte.
Signature : si vous avez généré une clé secrète, l'en-tête X-Webhook-Signature est un HMAC-SHA256 du corps brut (voir Contenu des webhooks et vérification de la signature). Un Custom webhook décode le corps pour vous : une vérification stricte est plus simple dans votre propre endpoint. Sinon, gardez l'adresse du webhook confidentielle.
La carte Make de Paramètres → Intégrations n'est pas nécessaire pour cette configuration.

Dépannage

Le scénario ne montre que message dans les données : la structure a été apprise à partir de l'événement de test. Redéterminez la structure et déclenchez une vraie modification de contact.
401 renvoyé par le module HTTP : vérifiez la valeur de l'en-tête, Bearer puis le token.