Un identifiant de compte désigne un compte LinkedIn connecté. Vous en recevez un quand une connexion aboutit, et vous le remettez dans presque tous les appels suivants — dans un segment de chemin, un paramètre de requête, un champ JSON ou un champ multipart, selon l'opération.
Il est opaque. Pas de préfixe, ce n'est pas un UUID, et il ne porte aucun sens qu'il faudrait analyser. Traitez-le comme une chaîne que vous stockez et renvoyez.
Pourquoi il répond 404 et pas 403
Chaque abonné de la MakeHybrid API est transféré vers un unique tenant partagé chez le fournisseur externe, ce qui veut dire que les identifiants de compte de tous les clients vivent dans le même espace de noms. Rien n'atteint ce fournisseur en nommant un identifiant de compte tant que nous n'avons pas confirmé que votre organisation l'a connecté.
Un échec répond 404, jamais 403. La différence n'est pas une politesse. Un 403 signifierait que l'id existe et n'est pas le vôtre — quelqu'un pourrait donc générer des ids à la chaîne et distinguer les vrais des faux selon la réponse reçue. Un 404 dans les deux cas ne dit rien du tout.
C'est vérifié aux quatre endroits par lesquels un id peut arriver : le chemin, la chaîne de requête, un champ du corps JSON et un champ multipart. Un id qui atteindrait le fournisseur sans vérification serait une lecture entre locataires.
Questions fréquentes
Faut-il donner l'identifiant de compte à un agent IA ?
Il peut le trouver. Un assistant connecté par MCP, ou un agent IA de salle avec MakeHybrid coché, liste les comptes connectés de l'organisation et prend l'account_id dans la réponse. Nommer le compte en langage courant suffit en général.
Un agent IA peut-il utiliser l'identifiant de compte d'une autre organisation ?
Non. L'identifiant est vérifié par rapport à l'organisation à laquelle appartient la clé, et l'identifiant d'une autre organisation répond 404 à un agent IA exactement comme à du code.