Guide développeur
Créez votre outil d'automatisation de netlinking avec l'API BlogDrip
Connectez votre logiciel directement à BlogDrip et automatisez les commandes d'articles invités. Construisez des workflows SEO personnalisés, intégrez vos applications existantes et gérez les opérations de netlinking plus efficacement.
Pourquoi automatiser
Pourquoi créer votre propre outil d'automatisation de netlinking
Les agences SEO et les équipes marketing internes rencontrent le même schéma opérationnel : recherche manuelle d'opportunités de publication, ressaisie des commandes d'articles invités, gestion simultanée de plusieurs campagnes clients, transfert d'informations entre systèmes internes, suivi de l'avancement des commandes et tentative de mise à l'échelle sans augmenter proportionnellement les effectifs.
Une intégration API retire le travail mécanique répétitif des mains de votre équipe et le fait passer par du code. Votre logiciel existant — CRM, outil de gestion de campagnes ou tableau de bord personnalisé où votre équipe travaille déjà — communique directement avec la place de marché. Les opérateurs restent concentrés sur la stratégie, les briefs et le contrôle qualité au lieu de la saisie des commandes.
L'automatisation apporte de l'efficacité aux workflows, pas des classements SEO. Elle ne fera pas réussir une campagne mal conçue et ne remplacera pas le jugement humain pour la sélection des éditeurs. Ce qu'elle fait bien, c'est supprimer la couche de saisie de données, de sorte que lorsque vous décidez quoi acheter, vous puissiez l'exécuter à n'importe quel volume.
Ce que vous pouvez créer
Ce que vous pouvez construire avec l'API BlogDrip
Patrons pratiques pour des logiciels construits au-dessus d'une intégration programmatique de la place de marché.
Tableau de bord personnalisé d'articles invités
Une application interne qui se connecte à BlogDrip et soumet des commandes d'articles invités prises en charge depuis une interface que votre équipe contrôle.
Système de gestion d'agence SEO
La commande d'articles invités intégrée dans un workflow d'agence existant, pour que les responsables de campagne ne quittent jamais l'outil qu'ils utilisent déjà.
Soumission automatisée de commandes
Des requêtes API créent des commandes d'articles invités prises en charge en lot, sans l'étape manuelle de saisie par commande.
Gestion des campagnes clients
Connectez les enregistrements clients et campagnes internes aux workflows de commande BlogDrip — une source de vérité pour savoir qui achète quoi.
Automatisation des workflows
Déclenchez des opérations API prises en charge depuis des processus métier internes — validations, lancements, vagues de campagne planifiées.
Reporting et supervision
Récupérez les informations liées aux commandes dans des outils de reporting personnalisés lorsque c'est pris en charge. Cadrez le reporting sur ce que l'API expose réellement plutôt que de supposer une visibilité temps réel complète.
Architecture
Exemple d'architecture d'automatisation
Une intégration saine sépare les responsabilités en quatre couches.
En haut, votre application d'automatisation externe — un tableau de bord personnalisé, un logiciel d'agence SEO, un CRM interne ou un système de gestion de campagnes. C'est là que votre équipe travaille au quotidien.
En dessous se trouve le backend de votre application. Ses responsabilités sont celles que toute intégration doit bien gérer : stocker `x-client-id` et `x-client-secret` de manière sécurisée, valider les entrées avant qu'elles n'atteignent BlogDrip, préparer et envoyer les requêtes API, gérer les réponses `{ data, pagination }`, consigner les événements opérationnels et gérer les retries de façon sûre pour qu'un incident réseau transitoire ne devienne pas une commande payée en double.
Ensuite, les requêtes atteignent l'Advertiser API de BlogDrip — la surface publique versionnée sous `/api/public/*` — qui expose la fonctionnalité de commande d'articles invités prise en charge.
L'API aiguillera les commandes vers la place de marché BlogDrip — plus de 275,000+ sites web d'inventaire total — puis vers le processus de traitement des commandes et le workflow de publication applicable. Selon le site sélectionné, la publication peut être manuelle côté éditeur ou automatisée via le plugin WordPress ou l'Agency API. Tous les sites de la place de marché ne supportent pas la Publication instantanée, donc votre intégration doit considérer le timing de publication comme dépendant du workflow, et non instantané.
Créez votre outil d'automatisation, étape par étape
Huit étapes du cadrage à la supervision. Considérez-les comme une référence, pas une séquence stricte — beaucoup s'exécutent en parallèle.
Définissez votre flux d'automatisation
Identifiez quelles tâches doivent être automatisées, quelles informations votre application nécessite, quand une commande doit être soumise, comment éviter les commandes en double, comment gérer les erreurs et comment les données de campagne sont stockées. Un exemple concret de cadrage : une agence gérant 20 clients, chacun avec 3–5 campagnes actives, veut que les nouvelles campagnes génèrent automatiquement des commandes pour une liste restreinte de sites pré-approuvés — mais seulement après qu'un humain ait approuvé le brief de campagne.
Obtenez l'accès à l'API BlogDrip
Ouvrez votre compte à app.blogdrip.com/settings et allez dans My Settings → API access pour trouver vos identifiants. Vous verrez deux valeurs : un `x-client-id` et un `x-client-secret`. Le secret est affiché une fois lors de sa création ou rotation, copiez-le immédiatement dans votre gestionnaire de secrets. L'accès nécessite un minimum de €500 par mois de dépenses totales sur le compte — les commandes manuelles comptent, les commandes via API comptent, les deux combinés. L'accès API est désactivé automatiquement si le minimum n'est pas atteint sur un mois donné. Les €500 sont un seuil de dépenses, pas des frais d'abonnement API séparés.
Lisez la documentation de l'API
La documentation officielle à app.blogdrip.com/api/public/docs/index.html décrit les endpoints exacts sous le namespace `/api/public/*`, l'authentification (les deux paires d'en-têtes mentionnées ci‑dessus), les méthodes de requête, les paramètres requis, les formats de réponse (les endpoints de liste enveloppent les réponses dans `{ data, pagination }` avec une pagination indexée à 0 `?page=0`), les erreurs de validation (`{ message }`) et les opérations de commande disponibles. Considérez la documentation comme la source d'autorité : si un paramètre n'est pas documenté, ne supposez pas qu'il existe.
Créez la connexion à l'API
Créez un backend d'application qui stocke `x-client-id` et `x-client-secret` de façon sécurisée (variables d'environnement, gestionnaire de secrets — jamais dans le code frontend), envoie des requêtes authentifiées avec les deux en-têtes, analyse les réponses, gère les erreurs et écrit des logs structurés pour chaque appel sortant. Gardez le client API comme un petit module bien testé afin que le reste de votre application ne parle jamais directement à BlogDrip.
Implémentez la commande automatisée d'articles invités
Connectez votre workflow interne aux opérations de commande BlogDrip prises en charge. Un flux typique : une nouvelle campagne est créée dans votre système → un site est sélectionné (résolvez son `marketSiteId` via les endpoints de la place de marché) → votre application prépare les informations de commande requises (titre, URL, description, `categoryId`, `marketSiteId`, `campaignId`, `scheduleDate` optionnel, `linkNoFollow`) → le backend valide la commande selon vos règles métier → l'application soumet la commande via l'Advertiser API → la réponse est enregistrée dans votre système pour la traçabilité. Validez chaque champ par rapport au spec OpenAPI avant d'envoyer.
Gérez les erreurs et les commandes en double
Validez les requêtes avant soumission, empêchez les commandes en double accidentelles (une clé d'idempotence ou une vérification de déduplication côté serveur de votre part est un modèle sûr), consignez chaque échec API avec suffisamment de contexte pour déboguer plus tard, gérez gracieusement les problèmes de connectivité temporaires et respectez les limites de débit documentées. Une règle à intégrer : ne relancez jamais automatiquement une requête de création de commande non-idempotente sans confirmation explicite humaine ou système — une relance sur une commande réussie dont vous n'avez pas vu la réponse crée une double facturation.
Testez votre intégration
Exécutez votre intégration contre un environnement sandbox si un tel environnement est documenté. Si aucun sandbox n'est disponible, testez en production avec prudence — n'exécutez jamais de suites de tests automatisées qui créent de vraies commandes payantes sans autorisation explicite. Utilisez une campagne de test dédiée avec une revue humaine avant la première commande automatisée, et limitez les tests automatisés à une courte liste blanche de sites que vous avez pré-approuvés pour les tests d'intégration.
Déployez et surveillez
Placez les identifiants dans votre magasin de secrets de production, ajoutez de la supervision pour les échecs d'intégration et les schémas inhabituels de soumission de commandes, suivez les résultats de soumission de commandes de bout en bout, conservez les logs opérationnels assez longtemps pour déboguer un incident vieux de deux semaines, surveillez les dépenses de votre compte pour ne pas perdre l'accès API en descendant sous le minimum mensuel de €500, et surveillez le changelog BlogDrip pour les mises à jour API qui pourraient nécessiter une maintenance d'intégration.
Modèles d'intégration
À quoi ressemble une intégration saine
La source d'autorité pour des exemples exécutables est la spécification OpenAPI à app.blogdrip.com/api/public/openapi.json et la documentation lisible par l'humain à /api/public/docs. La spec est ce contre quoi votre code doit être généré ou vérifié — pas un extrait de page d'atterrissage qui pourrait devenir obsolète.
En pratique, une intégration propre suit généralement la même forme. Un module client API léger dans votre langage préféré — une fonction wrapper par opération nécessaire — gère la mécanique : il définit les en-têtes `x-client-id` et `x-client-secret` sur chaque requête, sérialise le corps de la requête, désérialise l'enveloppe `{ data, pagination }` sur les endpoints de liste (pagination indexée à 0), et convertit les réponses d'erreur (`{ message }`) en exceptions que votre logique métier peut intercepter proprement. Chaque wrapper a au moins un test qui vérifie la forme documentée, de sorte qu'un changement de schéma se révèle par un test échoué avant d'atteindre la production. Ce n'est qu'une fois que ce module est stable que vous le branchez au reste de votre application — déclencheurs de campagne, files de commandes, workers de retry, reporting.
Cette séquence rend l'intégration auditable : votre client API est une petite surface bien testée ; tout le reste communique avec BlogDrip via lui.
Bonnes pratiques
Ce qui rend une intégration API durable
Patrons qui maintiennent la santé des systèmes automatisés longtemps après le lancement.
Idempotence par conception
Considérez la création de commande comme coûteuse et irréversible. Dédupliquez de votre côté avant l'envoi de la requête — jamais après.
Hygiène des identifiants
Les identifiants API doivent être dans un gestionnaire de secrets, scindés par environnement. Faites-les tourner au départ d'un employé, pas seulement en cas de compromission.
Journalisation structurée
Chaque paire requête + réponse doit avoir un ID de corrélation. Le vous du futur, déboguant une commande ancienne, remerciera le vous du présent.
Clients respectueux des limites de débit
Respectez les limites de débit documentées. Un client qui recule proprement s'adapte mieux qu'un client qui relance agressivement.
Humain dans la boucle
Bloquez le premier appel en production derrière une approbation humaine. Élargissez l'automatisation seulement après que l'intégration ait prouvé sa stabilité.
Surveillance des dépenses
Alertez lorsque les dépenses mensuelles du compte se rapprochent ou descendent sous €500. Perdre l'accès API en cours de campagne est pénible.
Questions fréquentes
À qui s'adresse l'API BlogDrip ?
Aux comptes annonceurs qui souhaitent connecter leur propre logiciel — un tableau de bord personnalisé, une plateforme d'agence SEO, un CRM interne — au flux de commande d'articles invités de BlogDrip. Les utilisateurs typiques sont des agences gérant des campagnes à volume, des équipes SEO internes intégrant un stack existant et des développeurs construisant des outils opérationnels pour un client ou un produit spécifique.
Faut-il être développeur pour utiliser l'API ?
Pour construire l'intégration elle-même, oui. L'API est une interface programmatique — son utilisation nécessite d'écrire du code ou de travailler avec un développeur. Si vous souhaitez les bénéfices opérationnels sans le travail d'intégration, l'interface de la place de marché couvre manuellement la même fonctionnalité de commande.
Quelles sont les conditions d'accès ?
Un compte BlogDrip actif qui dépense au moins €500 par mois au total — les commandes manuelles et API comptent toutes deux pour le seuil. L'accès API est désactivé automatiquement si votre compte dépense moins sur un mois donné. Les €500 constituent un seuil de volume, pas des frais d'abonnement API séparés.
Où se trouve la documentation de l'API ?
La documentation officielle de l'API est publiée à app.blogdrip.com/api/public/docs/index.html, avec la spécification OpenAPI lisible machine à app.blogdrip.com/api/public/openapi.json. Les deux décrivent le schéma d'authentification, le catalogue complet des endpoints sous le namespace `/api/public/*`, les formes de requête et de réponse, le format de pagination et les réponses d'erreur. Considérez-les comme la source de vérité pour votre intégration.
Où trouver mes identifiants API ?
Dans My Settings → API access sur app.blogdrip.com/settings. Vous obtiendrez un `x-client-id` et un `x-client-secret` ; les deux doivent être inclus dans chaque requête authentifiée en tant qu'en-têtes HTTP. Le secret est affiché une seule fois lors de sa création ou rotation — copiez-le immédiatement dans votre gestionnaire de secrets, car il ne peut pas être récupéré plus tard. Les identifiants sont liés au compte ; traitez-les comme n'importe quel autre secret et ne les stockez pas dans le contrôle de version.
Comment fonctionne la pagination sur les endpoints de liste ?
Les endpoints de liste enveloppent leurs réponses dans `{ data, pagination }` et utilisent une pagination indexée à 0 — passez `?page=0` pour la première page, `?page=1` pour la seconde, et ainsi de suite. Le bloc pagination dans la réponse indique s'il existe d'autres pages. Si vous migrez depuis l'interface legacy `/api/<path>`, la forme de la réponse reste la même — seul le chemin de base passe à `/api/public/*`.
L'API prend-elle en charge les webhooks ?
Consultez la spec OpenAPI à app.blogdrip.com/api/public/openapi.json pour la liste actuelle des mécanismes de callback ou de notification d'événements pris en charge. Si une fonctionnalité n'est pas listée, construisez votre intégration sans supposer son existence — interroger l'API selon votre propre planning est une solution de repli sûre.
Y a-t-il un environnement sandbox ?
La réponse autoritaire figure dans la documentation API actuelle. Si un sandbox est listé, utilisez-le pour les tests d'intégration. Si aucun n'est listé, ne créez pas de vraies commandes payantes pendant les tests automatisés sans autorisation explicite — utilisez plutôt une campagne de test dédiée et une revue humaine.
Les commandes via l'API peuvent-elles utiliser la Publication instantanée ?
La disponibilité de la Publication instantanée dépend du site sélectionné et de l'intégration de publication automatisée prise en charge (soit le plugin WordPress BlogDrip, soit une connexion Agency API). Toute commande — API ou manuelle — passée sur un site éligible peut bénéficier de la publication automatisée. Tous les sites de la place de marché ne la supportent pas, donc votre intégration doit considérer le timing de publication comme dépendant du site, pas uniforme.
Quelle est la différence entre l'Advertiser API et l'Agency API ?
L'Advertiser API s'adresse aux clients qui veulent automatiser la commande d'articles invités depuis leur propre logiciel. L'Agency API s'adresse aux agences externes, plateformes de netlinking et réseaux d'éditeurs qui veulent connecter leur propre inventaire à BlogDrip et automatiser l'exécution prise en charge. Les deux sont indépendantes — l'utilisation de l'une n'oblige pas à utiliser l'autre.
Que se passe-t-il si je réessaie une requête de création de commande échouée ?
Si vous n'avez pas vu de réponse confirmée, supposez que la première requête a peut‑être réussi côté serveur. Ne relancez pas automatiquement la création de commande non-idempotente. Ajoutez une clé de déduplication côté serveur, ou interrogez la présence d'une commande éventuellement créée avant de réessayer — selon ce que votre workflow supporte proprement. Une relance sur une commande réussie mais dont vous n'avez pas vu la réponse crée une double facturation.
Prêt à automatiser votre netlinking ?
Ouvrez la documentation API, générez vos identifiants et commencez à construire. La place de marché s'adapte à votre automatisation — pas l'inverse.