Fonctionnement des crédits Email Verifier

Email Verifier utilise des crédits. Le tableau de bord affiche l’allocation du forfait et les crédits achetés, afin que vous connaissiez le coût exact avant le début d’une tâche.

Coût d’une vérification

Dans une tâche Deep, les adresses de fournisseurs ne donnant pas de preuve utile au niveau de la boîte coûtent 1 crédit. L’estimation du tableau de bord et de l’API calcule ce coût à partir des adresses de votre liste. Utilisez le total affiché au lieu de multiplier la taille de la liste par deux.

Allocation mensuelle

Les crédits mensuels ne sont pas reportés. Le vérificateur affiche votre solde actuel et la date de réinitialisation. Si vous en avez besoin de davantage avant cette date, achetez un pack.

Packs de crédits

Les prix affichés au checkout utilisent la devise de facturation de votre compte lorsqu’elle est disponible. Les crédits achetés n’expirent pas.

Pour acheter un pack, ouvrez Email Verifier, sélectionnez Buy Credits, choisissez la quantité et terminez le checkout dans le tableau de bord.

Exemples de sélection d’un pack

Ces exemples servent à planifier et ne constituent pas des totaux annoncés au checkout. L’aperçu du prix avant le lancement indique le montant qui compte pour les adresses réellement envoyées.

Actions utilisant ou non des crédits

Cette distinction est utile quand un fichier source nécessite un nettoyage. Vous pouvez préparer, examiner et corriger la liste avant le lancement. Les crédits paient le travail de vérification, pas la recherche de la colonne contenant les adresses.

Solde utilisé en premier

Sur l’hôte TrekMail standard, une vérification consomme d’abord l’allocation mensuelle, puis les crédits achetés. Vous utilisez ainsi l’allocation incluse avant d’entamer un pack.

Sur un hôte White Label, la vérification utilise le solde acheté. L’allocation du forfait de messagerie appartient au compte TrekMail de l’agence et n’est pas exposée dans son produit personnalisé.

Pourquoi le solde peut sembler différent

Sur l’hôte TrekMail normal, le panneau sépare les montants mensuels et achetés. L’allocation mensuelle est liée au forfait et se réinitialise selon le calendrier affiché. Un pack acheté constitue un solde distinct. Sur un hôte White Label, les utilisateurs voient le solde qu’ils peuvent réellement dépenser, à savoir le solde acheté.

Si une intégration lit les crédits via l’API, utilisez total_available pour comparer le solde à l’estimation d’une nouvelle tâche. Sur l’hôte normal, l’API renvoie aussi les parts mensuelle et achetée. N’ajoutez pas le solde d’un hôte à une requête envoyée à un autre.

Changements de forfait de messagerie

L’allocation mensuelle suit le forfait effectif du compte. Après un changement de forfait, consultez dans le panneau des crédits le montant et sa prochaine réinitialisation. Les crédits achetés restent un solde distinct. Une modification d’allocation n’efface donc pas un pack déjà acheté.

Avant le lancement d’une tâche groupée

Le vérificateur extrait les adresses, supprime les doublons et affiche une estimation avant que vous sélectionniez Start Verification. Vérifiez :

• le nombre d’adresses uniques ;
• le mode sélectionné ;
• le coût réel en crédits ;
• si le solde couvre toute la tâche.

Les crédits sont déduits au lancement. Si le solde ne couvre pas la liste, la tâche ne démarre pas. Vous n’obtenez donc pas une vérification partiellement financée.

Si vous envoyez la même liste normalisée dans le même mode dans un délai de 24 heures, TrekMail renvoie la tâche existante sans dépenser de nouveaux crédits.

Si la source contient des doublons

Les doublons d’une liste sont normalisés avant le calcul du prix. La même adresse n’est donc pas facturée deux fois dans cette tâche. Cela ne justifie pas d’ignorer les contacts en double dans le système source. Conservez si possible un enregistrement canonique par contact, sinon les rapports et la gestion des désabonnements peuvent devenir incohérents même si le coût est correct.

Lors d’un nouvel envoi pendant la fenêtre de protection contre les doublons, considérez la tâche existante renvoyée comme référence. Elle peut être encore en cours ou déjà prête. Cette approche est plus sûre que de multiplier les envois jusqu’à ce qu’une réponse incertaine du navigateur ou du réseau semble réussir.

Annulation et résultats

Vous pouvez annuler une tâche en attente ou en cours. Les lignes traitées restent disponibles et les crédits du travail non traité sont remboursés. Les tâches et résultats sont conservés 15 jours. Téléchargez donc l’export nécessaire avant la fin de ce délai.

Si une tâche est terminée, son annulation ne génère aucun remboursement puisqu’il ne reste aucun travail non traité. Si un envoi échoue avant la préparation d’une tâche, TrekMail traite le prélèvement comme un échec de démarrage au lieu de laisser une tâche payée inexistante. En cas d’anomalie, consultez l’historique avant d’envoyer une autre copie.

Rappel sur la conservation

La fenêtre de résultats de 15 jours est distincte du solde. Un crédit peut avoir été correctement dépensé même si le résultat détaillé n’est plus conservé. Téléchargez l’export CSV ou texte nécessaire aux audits et campagnes pendant sa disponibilité, puis protégez ces données de contacts selon votre processus de confidentialité.

Simplifier la comptabilité

Nommez la tâche pour faciliter les examens ultérieurs. Des noms comme September newsletter import ou Partner A sample sont plus utiles qu’une date générique. Enregistrez l’export et l’ID de tâche avec le dossier de campagne. Un examinateur disposera ainsi de la source, du coût estimé, du prélèvement réel et du segment obtenu sans reconstruire la décision depuis une boîte de réception.

Surveiller le solde

Le vérificateur avertit lorsque le solde disponible est faible. Vérifiez l’estimation avant une grande liste, surtout en mode Deep. Pour les processus automatisés, utilisez GET /api/v1/verify/credits afin de lire le solde actuel avant d’envoyer une tâche.

Ne lancez pas plusieurs envois volumineux simultanément à partir d’une ancienne vérification du solde. Relisez le solde avant chaque admission, utilisez une clé d’idempotence distincte pour chaque requête groupée de l’API et consignez la valeur credits_charged renvoyée. Vous éviterez les surprises quand plusieurs intégrations partagent un compte.

Si un solde ou un achat semble incorrect

Actualisez le vérificateur et confirmez que vous êtes sur l’hôte TrekMail ou White Label voulu. Consultez ensuite l’historique pour rechercher une tâche déjà créée. Si vous contactez l’assistance, fournissez l’ID et le nom de la tâche ainsi que l’erreur visible ou la référence d’achat. Ne fournissez jamais de jeton API, numéro de carte complet, mot de passe de boîte mail ou export complet de contacts.

Consultez Prix et packs de crédits Email Verifier pour des exemples de planification.