Trouver et exploiter les APIs privées de ses outils favoris
Nous allons voir comment trouver et exploiter l'API de Linkedin
Hello ! Aujourd’hui, sujet un peu technique que je vais essayer de vous expliquer simplement :
Trouver et exploiter les APIs privées de ses outils favoris
C’est la stratégie que j’ai adoptée pour l’Email Finder, le produit numéro un du challenge.
Je vais commencer par vous expliquer quelques notions, puis on s’attaquera à l’API de Substack et de Linkedin.
C’est parti ⬇️
Une API c’est quoi ?
Élément central du sujet du jour, qu’est-ce qu’une API ?
API = Application Programming Interface, c’est donc une interface.
Une interface qui permet l’échange de services, de données.
Pour faire l’analogie, vous allez au bar et vous demandez une pinte au serveur, il va alors aller derrière le comptoir, préparer la pinte et vous la ramener à table.
L’API c’est le barman ! Il prend votre commande, l’exécute, et vous donne le résultat : la pinte.
En informatique, une commande se fait via une URL (appelé endpoint) à laquelle on va ajouter les données nécessaires à l’exécution de la commande, appelées “payload” (est-ce que c’est une pinte de blonde ? de brune ?).
Plus concrètement, quand vous rentrez une URL dans votre navigateur, vous demandez à l’API de vous renvoyer le contenu d’une page, et la page s’affiche.
Et souvent la page reçue n’est pas complète, il n’y a que le squelette de la page web, et de nouvelles requêtes APIs sont faites, sans que vous vous en rendiez compte.
Ce sont ces requêtes qui nous intéressent aujourd’hui.
Pourquoi on parle d’API privée ou publique ?
Beaucoup d’outils proposent aujourd’hui une API publique, que les clients peuvent utiliser librement. La documentation de ces APIs est souvent accessible à tous (exemple : API de Aircall), vous pouvez donc savoir quelle requête vous donnera quel résultat / réponse.
Cependant certains outils n’ont pas d’API publique (à l’image de Substack et Linkedin), donc pas de documentation.
Il faut donc creuser un peu pour trouver comment elle fonctionne et l’exploiter.
On parle de “reverse engineering”.
Comment trouver une API privée ?
C’est là que devient plus technique.
Votre navigateur web, possède une fonctionnalité appelée DevTool, qui peut vous aider à modifier les pages à la volée, à diagnostiquer rapidement les problèmes d’une page web, suivre les cookies utilisés et les requêtes APIs.
Pour ouvrir le DevTool d’une page web :
Ctrl + Maj + C
sous Windows et LinuxCommand + Control + C
sur macOs
Cette magnifique page s’ouvre :
Cette page contient plusieurs onglets, je ne vais pas les détailler, celui qui nous intéresse ici est l’onglet “Network”. C’est dans cet onglet qu’on peut suivre toutes les requêtes entre la page et l’API.
Exemple sur mon profil Linkedin :
Vous verrez qu’il y a beaucoup de choses qui se passent, sans que vous le sachiez. 😅
Tout n’est pas intéressant pour nous, et il faut trouver la requête qui donnera la réponse qu’on souhaite.
Exemple ⬇️
Exemple 1 : Substack
Substack ne permet pas d’ajouter des subscribers via une API publique.
Et pourtant, leur API privée peut le faire.
Pour trouver comment cela fonctionne, j’ouvre ma page https://12months.substack.com, et j’ouvre le Devtool.
Je me place sur l’onglet Network du DevTool.
Puis je réalise une inscription classique sur Substack, en suivant ce qu’il se passe :
Je vois alors cette requête :
Avec ce payload :
Je comprends alors que c’est cette requête qui fait le travail, et que l’email qui sera ajouté dans mes subscribers est :
Je peux désormais utiliser l’API privée dans Make ou n8n si je le souhaite.
Et voici à quoi ressemblerait la requête :
Exemple 2 : Linkedin
Dans le cadre de l’Email Finder, produit du mois dernier, j’avais besoin de récupérer depuis un profil Linkedin : le prénom, le nom du profil et le nom de domaine de l’entreprise.
Pour pouvoir appliquer la logique, expliquée dans ce post.
Avec le même procédé utilisé ci-dessus, j’ai trouvé les URLs nécessaire.
Je vous les donne, c’est cadeau ⬇️
Pour récupérer le prénom et le nom du profil :
https://www.linkedin.com/voyager/api/identity/dash/profiles?q=memberIdentity&memberIdentity={public_id}&decorationId=com.linkedin.voyager.dash.deco.identity.profile.WebTopCardCore-9
Pour récupérer les expériences / entreprises du profil :
https://www.linkedin.com/voyager/api/identity/dash/profiles?q=memberIdentity&memberIdentity={public_id}&decorationId=com.linkedin.voyager.dash.deco.identity.profile.TopCardSupplementary-111
Pour récupérer les infos de l’entreprise, dont le nom de domaine :
https://www.linkedin.com/voyager/api/voyagerOrganizationDashCompanies/{company_id}?decorationId=com.linkedin.voyager.dash.deco.organization.MemberCompany-74
⚠️ En pensant à remplacer {public_id} par votre identifiant public Linkedin.
Il se trouve dans l’URL de votre profil : https://www.linkedin.com/in/antoine-baudot/
⚠️ En pensant à remplacer {company_id} par l’identifiant public de l’entreprise.
🟥 Mais ce n’est pas suffisant 🟥
Si vous utilisez ces URLs telles quelles, vous allez recevoir une erreur.
L’API est sécurisée et vous devez être authentifié comme client, pour pouvoir l’utiliser.
Alors comment faire ?
En testant une URL avec un outil pour faire des requêtes, j’obtiens l’erreur avec comme message “CSRF check failed”.
Par mon expérience, je sais que le CSRF est une méthode utilisée pour authentifier des requêtes APIs, via un token.
Cela se confirme en regardant de plus près la requête dans le DevTool :
On voit qu’une valeur “csrf-token“ est envoyée avec la requête.
Pour info, ce token doit se trouver dans sur votre navigateur, souvent dans les cookies. Vous pouvez y accéder également à l’aide du DevTool.
Pour Linkedin, vous trouverez le token dans le cookie appelé : JSESSIONID.
🟩 On a tout ce qu’il faut 🟩
Hop, je rajoute mon token CSRF à ma requête, et bingo !
(Une API vous répond, en général, avec le code 200 quand c’est un succès).
Ainsi, je peux récupérer tout ce qu’il me faut pour utiliser l’Email Finder.
Et ces requêtes sont faites par l’extension chrome directement.
Conclusion
On est arrivé au bout !
Je suis super intéressé par vos retours : est-ce que c’était assez clair ? Trop technique ? Trop long ?
C’était un sacré job d’écrire cette édition en essayant de vulgariser le sujet.
Merci d’avance pour vos feedbacks. 🥰
J’allais oublier :
La semaine prochaine, je sors le produit numéro 2 du challenge
À très vite !
J'aime bien les posts détaillés comme celui-ci ! 👏👏
D'ailleurs je compte bien utiliser l'API privée de Substack pour ajouter du monde sur la NL héhé
Pour aller plus loin, tu peux même voir les requêtes des applications qui ne sont pas dans le navigateur avec cette super app: https://proxyman.io (MacOS)
Hâte de voir le prochain projet 😎
C'est top merci beaucoup!🙏 Bonne équilibre entre technique et vulgarisation. Faudrait peut être un avertissement pour éviter que les gens se fassent flag leurs comptes LinkedIn s'ils font trop de requête d'un coup, non?