apollo.

crée une clé api dans les réglages développeur/api de ton compte apollo.

une clé plateforme free-tier (quota quotidien) si tu n'en poses pas la tienne — elle

interroge la base PARTAGÉE Apollo, la même pour tout le monde.

dit qu'il repart à minuit — la réponse d'un appel réussi porte aussi platform_quota

(used/limit/remaining) pour t'arrêter avant le refus au milieu d'un lot. Pose ta

propre clé pour lever la limite tout de suite, ou pour CE lead : hunter_email_finder

(email) et kaspr_enrich_linkedin / fullenrich_enrich_linkedin (téléphone,

historique LinkedIn) — source différente, pas de crédit brûlé sur un appel qui

échouerait de toute façon.

Apollo facture un reveal EN PLUS du match, alors que notre compteur plateforme ne sait

débiter qu'un match nu. C'est vrai du téléphone (~9 crédits là où un match nu en coûte

1) comme des emails personnels (pot distinct, barème selon le plan — écart non mesuré,

donc pas débitable non plus). apollo_match_person continue de marcher sans ta clé, il

ne rend simplement ni mobile, ni direct dial, ni email personnel.

sur ces outils-là, il te faut ta propre clé. Pas seulement pour écrire : même les lister

ou les lire rend TES données (ton carnet de contacts, tes boîtes connectées, le contenu

de tes emails envoyés, tes transcripts d'appels) — une clé plateforme mutualisée

exposerait ça à n'importe quel autre utilisateur d'oto.

Integrations → API) : une clé standard authentifie mais rend 403 sur ces trois-là.

recherche et enrichis entreprises et personnes, et repère les signaux de recrutement.

construction de liste : un search rend des centaines de noms obfusqués, et c'est par

là qu'on les révèle (300 personnes = 30 appels, pas 300). ⚠️ **le lot n'économise

aucun crédit** — apollo facture à la PERSONNE, exactement comme 10 appels unitaires ;

ce qu'il économise, ce sont les appels et le rate limit. les reveals (emails

personnels, téléphones) y demandent ta propre clé, comme en unitaire.

⚠️ la fiche entreprise imbriquée est allégée par défaut sur apollo_match_person et

apollo_bulk_match : stack technique, levées de fonds, filiales et mots-clés pesaient

91 % du payload — un seul match sortait à 60 000 caractères et dépassait la limite de

sortie des clients MCP. le nom, le domaine, le téléphone, l'effectif et le secteur

restent ; full=True rend le brut, au même prix. en lot, chaque fiche perd aussi

employment_history et account (la fiche société de ton CRM apollo) : sans ça, un

lot de 10 sortait à ~86 000 caractères.

⚠️ le seul geste d'apollo qui ne rend pas son résultat. apollo ne renvoie jamais un

mobile dans la réponse : il le vérifie de son côté et le POSTe à une url, quelques

minutes plus tard. la réponse immédiate ne porte qu'un request_id.

apollo, ~9 crédits. webhook_url est obligatoire côté apollo : c'est une url

HTTPS que TU contrôles (un endpoint n8n ou make, ton service) — **oto n'est pas un

receveur de webhook**, et ne voit pas ce qui y atterrit.

crédit, pendant 30 jours**. c'est par là que le numéro revient à l'agent : tu n'as pas

à lire toi-même ce qu'apollo a posté.

« Master »), d'après la doc apollo — même famille de prérequis que les outils de

contact. à vérifier sur une vraie clé : si elle ne l'a pas, le reveal part quand même

et les numéros arrivent sur ton webhook, mais apollo_reveal_phone_result refusera.

crédits sont dépensés et il ne reste rien à relever. passé 30 jours, le résultat

disparaît pour de bon.

traiter comme non authentifié, et à rendre idempotent.

reviennent bien dans la réponse (synchrone), sur ta propre clé apollo (même règle

de coût que le téléphone). apollo les retient pour les personnes en zone RGPD : un

résultat vide est une réponse, pas une panne.

ENREGISTRÉ chez toi : titre, email, téléphones, stage, listes, champs personnalisés

partagée). ⚠️ L'autre source, souvent déjà payée : apollo_match_person porte le

contact id IMBRIQUÉ à person.contact.id, dès que la personne est un contact chez

toi. Un id d'apollo_search_people est un id de PERSONNE et sera refusé ici.

Le même contact_id sert ensuite à apollo_sequence_contacts(op=add)

partagée Apollo, apollo_contact ne voit que ce que ton équipe a déjà

enregistré. Une personne trouvée mais jamais enregistrée n'a pas d'id de contact

apollo_match_person en coûte un et rend la fiche partagée, pas tes valeurs

est keyée par id de champ, jamais par nom. Pour une liste de choix, la

valeur à écrire est l'id de l'option, pas son libellé

Apollo (utile quand le compte appartient au client). ⚠️ Pour un texte long —

une accroche, un paragraphe — c'est field_type="textarea" : string est

plafonné à 120 caractères et Apollo tronque sans rien dire. Un champ portant

déjà ce nom fait REFUSER la création plutôt que d'en créer un homonyme

Integrations → API) ; une clé standard authentifie mais rend 403

connectées / plannings d'envoi), à appeler avant de créer une séquence ou d'y enrôler

des contacts

séquence

contacts, consulter leur activité. add démarre une campagne automatisée vers des

personnes réelles — dry_run disponible

send envoie (toujours deux appels distincts). search/content rendent TES emails

envoyés (corps inclus), pas une base partagée

enregistrements. Le coût crédit d'un get dépend de la présence d'insights IA,

imprévisible avant l'appel