Authentification
Chaque requête de vérification est authentifiée par une clé API envoyée en bearer.
Authorization: Bearer pm_live_votre_cle
Format des clés
Les clés sont préfixées pour les distinguer d'un coup d'œil :
pm_live_...: clés de production, débitées sur votre portefeuille.pm_test_...: clés bac à sable pour l'intégration.
La clé brute n'est affichée qu'une seule fois, à la création. Seul son hash est stocké, donc conservez-la en lieu sûr. En cas de perte, révoquez-la et créez-en une nouvelle.
Mode bac à sable
Une clé pm_test_ exécute un bac à sable déterministe : elle n'ouvre jamais de connexion SMTP, ne touche jamais une vraie boîte mail et ne réserve rien sur votre portefeuille, pour brancher une intégration sans dépenser de crédits. Le résultat est choisi d'après la partie locale de l'adresse, pour que vos tests s'appuient sur un contrat stable :
valid@...renvoie un résultat délivrable avec un score élevé.invalid@...renvoie un résultat non délivrable.catchall@...,disposable@...etrole@...renvoient le résultat risqué correspondant.- Toute autre partie locale renvoie un résultat délivrable avec un score modéré.
La forme de la réponse est identique à une vérification réelle, donc le même code gère les deux. Passez à une clé pm_live_ pour lancer le vrai pipeline.
Portées et contrôles
Une clé porte des portées granulaires et l'ensemble des contrôles qu'elle peut lancer (par exemple le SMTP n'est disponible que sur les plans qui l'incluent). La limite de débit dépend du plan et n'est pas modifiable par clé.
Facturation
La vérification est débitée depuis votre portefeuille de jetons, pas par requête. Un appel réserve le coût estimé au départ, puis le valide ou le rembourse une fois le job terminé : vous ne payez donc que les contrôles réellement exécutés. Quand le portefeuille est vide, l'API renvoie 402 Payment Required, distinct d'une erreur de portée 403, pour que votre SDK distingue « recharger » de « permission manquante ».