Skip to content
Cerca

Guida per sviluppatori

Crei il suo strumento di automazione per link building con l'API di BlogDrip

Connetta il suo software direttamente a BlogDrip e automatizzi gli ordini di guest post. Crei workflow SEO personalizzati, integri le applicazioni esistenti e gestisca le operazioni di link building in modo più efficiente.

Perché automatizzare

Perché creare il proprio strumento di automazione per link building

Le agenzie SEO e i team di marketing interni riscontrano lo stesso schema operativo: ricerca manuale di opportunità editoriali, reinserimento degli ordini di guest post, gestione simultanea di più campagne cliente, trasferimento di informazioni tra sistemi interni, monitoraggio dello stato degli ordini e tentativi di scalare il tutto senza aumentare proporzionalmente il personale.

Un'integrazione API toglie al suo team il lavoro ripetitivo e meccanico, instradandolo tramite codice. Il software che già utilizzate — CRM, strumento di gestione campagne o dashboard personalizzata — parla direttamente con il marketplace. Gli operatori restano concentrati sulla strategia, sui brief e sul controllo qualità invece che sull'inserimento degli ordini.

L'automazione migliora l'efficienza dei flussi di lavoro, non le classifiche SEO. Non farà funzionare una campagna scadente né sostituirà il giudizio umano nella selezione degli editori. Ciò che fa bene è rimuovere il livello di inserimento dati, così quando decidete cosa acquistare potete eseguirlo a qualsiasi volume.

SEO team automating repetitive link building tasks

Cosa può creare

Cosa può costruire con l'API di BlogDrip

Modelli pratici per software costruito sopra un'integrazione programmabile del marketplace.

  • Dashboard personalizzato per guest post

    Un'applicazione interna che si collega a BlogDrip e invia ordini di guest post supportati da un'interfaccia controllata dal suo team.

  • Sistema di gestione per agenzie SEO

    Ordinazione di guest post integrata in un workflow agenzia esistente, così i responsabili delle campagne non lasciano mai il sistema che già usano.

  • Invio automatico degli ordini

    Richieste API che creano ordini di guest post supportati in batch, senza il passaggio manuale per ogni singolo ordine.

  • Gestione campagne cliente

    Colleghi i record interni di cliente e campagna ai workflow di ordinazione di BlogDrip — una fonte di verità su chi acquista cosa.

  • Automazione dei workflow

    Attivi le operazioni API supportate da processi aziendali interni — approvazioni, avvii, ondate di campagna programmate.

  • Reporting e monitoraggio

    Importi le informazioni correlate agli ordini in strumenti di reportistica personalizzati dove supportato. Limiti il reporting a quanto l'API espone effettivamente anziché presumere visibilità in tempo reale completa.

Architettura

Esempio di architettura di automazione

Una buona integrazione separa le responsabilità su quattro livelli.

In cima, la sua applicazione di automazione esterna — una dashboard personalizzata, software per agenzie SEO, CRM interno o sistema di gestione campagne. Qui è dove il suo team lavora quotidianamente.

Sotto si colloca il backend della sua applicazione. Le sue responsabilità sono quelle che ogni integrazione deve gestire correttamente: memorizzare in modo sicuro `x-client-id` e `x-client-secret`, convalidare l'input prima che raggiunga BlogDrip, preparare e inviare le richieste API, gestire le risposte `{ data, pagination }`, registrare eventi operativi e gestire i retry in modo sicuro affinché un'interruzione di rete transitoria non si trasformi in un ordine pagato duplicato.

Da lì le richieste colpiscono l'Advertiser API di BlogDrip — la superficie pubblica e versionata sotto `/api/public/*` — che espone la funzionalità supportata per l'ordinazione di guest post.

L'API instrada gli ordini nel marketplace di BlogDrip — più di 275,000+ siti web di inventario totale — e da lì nei processi di gestione ordine e pubblicazione applicabili. A seconda del sito selezionato, la pubblicazione può essere manuale da parte dell'editore o automatizzata tramite il plugin WordPress o l'Agency API. Non tutti i siti nel marketplace supportano Instant Publishing, quindi la sua integrazione dovrebbe trattare i tempi di pubblicazione come dipendenti dal workflow, non istantanei.

Four-layer architecture connecting an automation application to BlogDrip

Costruisca il suo strumento di automazione, passo dopo passo

Otto passaggi dallo scoping al monitoraggio. Trattateli come riferimento, non come sequenza rigida — molti possono procedere in parallelo.

  1. Definisca il workflow di automazione

    Identifichi quali attività devono essere automatizzate, quali informazioni la sua applicazione richiede, quando un ordine deve essere inviato, come prevenire ordini duplicati, come gestire gli errori e come vengono memorizzati i dati di campagna. Un esempio concreto di scoping: un'agenzia che gestisce 20 clienti, ciascuno con 3–5 campagne attive, vuole che nuove campagne generino automaticamente ordini per una shortlist di siti pre-approvati — ma solo dopo che un umano approva il brief della campagna.

  2. Ottenere l'accesso all'API di BlogDrip

    Apra il suo account su app.blogdrip.com/settings e vada su Le mie impostazioni → Accesso API per trovare le sue credenziali. Vedrà due valori: un `x-client-id` e un `x-client-secret`. Il secret viene mostrato una sola volta quando viene emesso o ruotato, quindi copielo immediatamente nel suo secret manager. L'accesso richiede una spesa minima di €500 al mese sul totale dell'account — gli ordini manuali contano, gli ordini API contano, entrambe le modalità sommate. L'accesso API viene disattivato automaticamente se la soglia minima non è raggiunta in un dato mese. I €500 sono una soglia di spesa, non una tariffa di abbonamento API separata.

  3. Legga la documentazione API

    La documentazione ufficiale su app.blogdrip.com/api/public/docs/index.html descrive gli endpoint esatti sotto il namespace `/api/public/*`, l'autenticazione (le due coppie di header menzionate sopra), i metodi di richiesta, i parametri richiesti, i formati di risposta (gli endpoint di lista avvolgono le risposte in `{ data, pagination }` con paginazione 0-based `?page=0`), gli errori di validazione (`{ message }`) e le operazioni di ordinazione disponibili. Tratti la documentazione come fonte autorevole: se un parametro non è documentato, non lo dia per scontato.

  4. Costruisca la connessione API

    Crei un backend applicativo che memorizzi in modo sicuro sia `x-client-id` sia `x-client-secret` (variabili d'ambiente, secret manager — mai nel codice frontend), invii richieste autenticate con entrambi gli header impostati, analizzi le risposte, gestisca gli errori e scriva log strutturati per ogni chiamata in uscita. Mantenga il client API come un modulo piccolo e ben testato così il resto dell'applicazione non parla mai direttamente con BlogDrip.

  5. Implementi l'ordinazione automatica di guest post

    Colleghi il suo workflow interno alle operazioni di ordinazione supportate da BlogDrip. Un flusso tipico: una nuova campagna viene creata nel suo sistema → viene selezionato un sito web (risolva il suo `marketSiteId` dagli endpoint marketplace) → la sua applicazione prepara le informazioni d'ordine richieste (titolo, URL, descrizione, `categoryId`, `marketSiteId`, `campaignId`, eventuale `scheduleDate`, `linkNoFollow`) → il backend valida l'ordine rispetto alle regole di business → l'applicazione invia l'ordine tramite l'Advertiser API → la risposta viene salvata nel suo sistema per tracciabilità. Convalidi ogni campo rispetto alla specifica OpenAPI prima dell'invio.

  6. Gestisca errori e ordini duplicati

    Convalidi le richieste prima dell'invio, prevenga ordini duplicati accidentali (una chiave di idempotenza o un controllo di de-duplica lato server è un pattern sicuro), registri ogni errore API con contesto sufficiente per il debugging successivo, gestisca con grazia problemi di connettività temporanei e rispetti eventuali limiti di velocità documentati. Una regola da interiorizzare: non ritentare automaticamente la creazione di un ordine non-idempotente senza conferma esplicita umana o di sistema — un retry su un ordine andato a buon fine di cui non si è vista la risposta genera un doppio addebito.

  7. Testi la sua integrazione

    Esegua l'integrazione contro un ambiente sandbox se è documentato. Se non è disponibile un sandbox, testi con attenzione in produzione — non esegua suite di test automatiche che creano ordini pagati reali senza autorizzazione esplicita. Usi una campagna di test dedicata con revisione human-in-the-loop prima che venga inviato il primo ordine automatizzato, e limiti le esecuzioni di test automatici a una allow-list ristretta di siti che ha pre-approvato per i test di integrazione.

  8. Distribuisca e monitori

    Spostare le credenziali nel suo secret store di produzione, aggiungere monitoraggio per i fallimenti dell'integrazione e pattern insoliti di invio ordini, tracciare i risultati di invio ordine end-to-end, conservare i log operativi a sufficienza per il debug di un incidente di due settimane fa, monitorare la spesa dell'account per non perdere l'accesso API scendendo sotto la soglia mensile di €500 e seguire il changelog di BlogDrip per aggiornamenti API che possano richiedere manutenzione dell'integrazione.

Modelli di integrazione

Com'è fatta una integrazione sana

La fonte autorevole per esempi eseguibili è la specifica OpenAPI su app.blogdrip.com/api/public/openapi.json e la documentazione leggibile su /api/public/docs. La spec è ciò con cui il suo codice dovrebbe essere generato o verificato — non uno snippet di landing page che può diventare obsoleto.

In pratica, una integrazione pulita tende a seguire la stessa forma. Un modulo client API sottile nella lingua preferita — una funzione wrapper per ogni operazione necessaria — gestisce la meccanica: imposta gli header `x-client-id` e `x-client-secret` su ogni richiesta, serializza il body della richiesta, deserializza l'involucro `{ data, pagination }` sugli endpoint di lista (paginazione 0-based) e converte le risposte di errore (`{ message }`) in eccezioni che la logica di business può intercettare chiaramente. Ogni wrapper ha almeno un test che asserisce la forma documentata, così un cambiamento di schema emerge come test fallito prima di raggiungere la produzione. Solo quando quel modulo è stabile lo collegherà al resto dell'applicazione — trigger di campagna, code di ordini, worker di retry, reportistica.

Questa sequenza mantiene l'integrazione auditabile: il suo client API è una superficie piccola e ben testata; tutto il resto parla con BlogDrip attraverso di esso.

Thin API-client module as a stable integration surface

Buone pratiche

Cosa mantiene duratura un'integrazione API

Modelli che mantengono i sistemi automatizzati sani a lungo termine dopo il lancio.

  • Idempotenza per progettazione

    Tratti la creazione degli ordini come costosa e irreversibile. Deduplichi sul suo lato prima che la richiesta venga inviata — mai dopo.

  • Igiene delle credenziali

    Le credenziali API devono stare in un secret manager, scoperte per ambiente. Ruotarle alla partenza, non solo in caso di compromissione.

  • Logging strutturato

    Ogni coppia richiesta + risposta ottiene un ID di correlazione. Il suo futuro sé che debugga un ordine vecchio la ringrazierà.

  • Client consapevoli dei rate limit

    Rispettare i limiti di velocità documentati. Un client che arretra pulitamente scala più di uno che ritenta aggressivamente.

  • Intervento umano

    Ponga la prima chiamata in produzione dietro approvazione umana. Espanda l'automazione solo dopo che l'integrazione si è dimostrata stabile.

  • Monitoraggio della spesa

    Allerti quando la spesa mensile dell'account tende verso o sotto i €500. Perdere l'accesso API a metà di una campagna è problematico.

Domande frequenti

A chi è destinata l'API di BlogDrip?

Account inserzionista che vogliono collegare il proprio software — una dashboard personalizzata, una piattaforma per agenzie SEO, un CRM interno — al workflow di ordinazione dei guest post di BlogDrip. Gli utenti tipici sono agenzie che gestiscono campagne su larga scala, team SEO interni che integrano con uno stack esistente e sviluppatori che costruiscono strumenti operativi per un cliente o prodotto specifico.

Devo essere sviluppatore per usare l'API?

Per realizzare l'integrazione, sì. L'API è un'interfaccia programmatica — usarla richiede di scrivere codice o di collaborare con uno sviluppatore. Se desidera i benefici operativi senza il lavoro di integrazione, l'interfaccia del marketplace copre manualmente le stesse funzionalità di ordinazione.

Quali sono i requisiti di accesso?

Un account BlogDrip attivo che spenda almeno €500 al mese in totale — ordini manuali e API contano entrambi per la soglia. L'accesso API viene disattivato automaticamente se il suo account spende meno in un dato mese. I €500 sono una soglia di volume, non una tariffa di abbonamento API separata.

Dove si trova la documentazione API?

La documentazione ufficiale dell'API è pubblicata su app.blogdrip.com/api/public/docs/index.html, con la specifica OpenAPI in formato macchina su app.blogdrip.com/api/public/openapi.json. Entrambe descrivono lo schema di autenticazione, il catalogo completo degli endpoint sotto il namespace `/api/public/*`, le forme di richiesta e risposta, il formato di paginazione e le risposte di errore. Tratti queste risorse come fonte di verità per la sua integrazione.

Dove trovo le mie credenziali API?

Su Le mie impostazioni → Accesso API in app.blogdrip.com/settings. Riceverà un `x-client-id` e un `x-client-secret`; entrambi devono essere inviati in ogni richiesta autenticata come header HTTP. Il secret viene mostrato una sola volta quando viene emesso o ruotato — copielo immediatamente nel suo secret manager, poiché non può essere recuperato in seguito. Le credenziali sono per account; trattatele come qualsiasi altro segreto e tengale fuori dal controllo versione.

Come funziona la paginazione sugli endpoint di lista?

Gli endpoint di lista avvolgono le loro risposte in un involucro `{ data, pagination }` e utilizzano paginazione 0-based — passi `?page=0` per la prima pagina, `?page=1` per la seconda, e così via. Il blocco di paginazione nella risposta indica se esistono altre pagine. Se sta migrando dall'interfaccia legacy `/api/<path>`, la forma della risposta è invariata — cambia solo il path base a `/api/public/*`.

L'API supporta i webhook?

Controlli la specifica OpenAPI su app.blogdrip.com/api/public/openapi.json per l'elenco corrente dei meccanismi di callback o notifiche di evento supportati. Se una funzionalità non è elencata, costruisca la sua integrazione senza presumere che esista — il polling dell'API a intervalli decisi da lei è un fallback sicuro.

Esiste un ambiente sandbox?

La risposta autorevole è nella documentazione API corrente. Se è elencato un sandbox, usi quello per i test di integrazione. Se non è elencato, non crei ordini pagati reali durante i test automatici senza autorizzazione esplicita — usi invece una campagna di test dedicata e una revisione human-in-the-loop.

Gli ordini API possono usare Instant Publishing?

La disponibilità di Instant Publishing dipende dal fatto che il sito selezionato disponga di un'integrazione di pubblicazione automatica supportata (o il plugin WordPress di BlogDrip o una connessione Agency API). Qualsiasi ordine — API o manuale — effettuato su un sito idoneo può beneficiare della pubblicazione automatizzata. Non tutti i siti nel marketplace lo supportano, quindi la sua integrazione dovrebbe trattare i tempi di pubblicazione come per-sito, non uniformi.

Qual è la differenza tra l'Advertiser API e l'Agency API?

L'Advertiser API è destinata ai clienti che vogliono automatizzare l'ordinazione di guest post dal proprio software. L'Agency API è pensata per agenzie esterne, piattaforme di link building e network di editori che vogliono collegare il proprio inventario a BlogDrip e automatizzare gli adempimenti supportati. Entrambe sono indipendenti — usare una non richiede l'altra.

Cosa succede se ritento una richiesta di creazione ordine fallita?

Se non ha visto una risposta confermata, assuma che la prima richiesta potrebbe essere riuscita lato server. Non ritenti automaticamente la creazione di ordini non-idempotenti. Aggiunga una chiave di de-duplica lato server o interroghi l'ordine eventualmente creato prima di ritentare — qualunque soluzione il suo workflow supporti chiaramente. Un retry su un ordine riuscito ma di cui non si è vista la risposta crea un doppio addebito.

Pronto ad automatizzare il suo link building?

Apra la documentazione API, generi le sue credenziali e inizi a sviluppare. Il marketplace scala con la sua automazione — non il contrario.