Skip to content
Caută

Ghid pentru dezvoltatori

Creați un instrument de automatizare pentru link building cu BlogDrip API

Conectați-vă software-ul direct la BlogDrip și automatizați plasarea comenzilor de guest post. Construiți fluxuri SEO personalizate, integrați aplicațiile existente și gestionați operațiunile de link building mai eficient.

De ce să automatizați

De ce să creați propriul instrument de automatizare pentru link building

Agențiile SEO și echipele interne de marketing întâmpină același tipar operațional: căutarea manuală a oportunităților de publicare, reintroducerea comenzilor de guest post, jonglarea cu multiple campanii de clienți, transferul informațiilor între sisteme interne, monitorizarea progresului comenzilor și încercarea de a scala toate acestea fără a mări proporțional echipa.

O integrare API ia munca mecanică repetitivă de pe umerii echipei dvs. și o rulează prin cod. Software-ul existent — CRM-ul, instrumentul de gestionare a campaniilor sau dashboardul personalizat în care echipa dvs. lucrează deja — comunică direct cu marketplace‑ul. Operatorii rămân concentrați pe strategie, briefuri și controlul calității în loc de introducerea comenzilor.

Automatizarea oferă eficiență în fluxurile de lucru, nu poziții SEO garantate. Nu va transforma o campanie slabă într-una de succes și nu va înlocui judecata umană în selectarea publisherilor. Ce face bine este să elimine stratul de introducere a datelor, astfel încât atunci când decideți ce să cumpărați să puteți executa la orice volum.

SEO team automating repetitive link building tasks

Ce puteți construi

Ce puteți construi cu BlogDrip API

Pattern-uri practice pentru software construit pe o integrare programatică cu marketplace-ul.

  • Dashboard personalizat pentru guest posting

    O aplicație internă care se conectează la BlogDrip și trimite comenzi de guest post acceptate dintr-o interfață pe care echipa dvs. o controlează.

  • Sistem de management pentru agenții SEO

    Plasarea comenzilor de guest post integrată în fluxul de lucru al agenției, astfel încât managerii de campanie să nu părăsească sistemul pe care îl folosesc deja.

  • Trimitere automată a comenzilor

    Cereri API care creează batch-uri de comenzi de guest post acceptate, fără pasul manual de introducere a fiecărei comenzi.

  • Gestionare campanii clienți

    Conectați înregistrările interne de clienți și campanii la fluxurile de comandă BlogDrip — o sursă unică de adevăr pentru cine cumpără ce.

  • Automatizare a fluxurilor de lucru

    Declanșați operațiuni API suportate din procesele interne de business — aprobări, lansări, valuri programate de campanii.

  • Raportare și monitorizare

    Preluați informații legate de comenzi în instrumente de raportare personalizate acolo unde API-ul le expune. Limitați raportarea la ce oferă efectiv API-ul, în loc să presupuneți vizibilitate completă în timp real.

Arhitectură

Arhitectură de automatizare — exemplu

O integrare sănătoasă separă responsabilitățile pe patru niveluri.

În partea de sus se află aplicația externă de automatizare — un dashboard personalizat, software pentru agenții SEO, CRM intern sau sistem de management al campaniilor. Aici lucrează echipa dvs. zilnic.

Dedesubt este backend‑ul aplicației dvs. Responsabilitățile sale sunt cele pe care orice integrare trebuie să le gestioneze corect: stocarea în siguranță a valorilor `x-client-id` și `x-client-secret`, validarea datelor înainte ca acestea să ajungă la BlogDrip, pregătirea și trimiterea cererilor API, tratarea răspunsurilor `{ data, pagination }`, logarea evenimentelor operaționale și gestionarea retry‑urilor în siguranță astfel încât un întreruperе temporară de rețea să nu se transforme într-o comandă plătită duplicat.

De acolo, cererile ajung la Advertiser API‑ul BlogDrip — suprafața publică, versionată, sub `/api/public/*` — care expune funcționalitatea suportată pentru plasarea comenzilor de guest post.

API‑ul direcționează comenzile către marketplace‑ul BlogDrip — peste 275,000 de site‑uri în inventarul total — și de acolo către fluxul de procesare a comenzilor și publicare aplicabil. În funcție de site‑ul selectat, publicarea poate fi manuală pe partea publisherului sau automatizată prin pluginul WordPress sau Agency API. Nu toate site‑urile din marketplace acceptă Instant Publishing, așa că integrarea dvs. ar trebui să trateze timpul de publicare ca dependent de fluxul de lucru, nu ca fiind instantaneu.

Four-layer architecture connecting an automation application to BlogDrip

Construiți instrumentul de automatizare, pas cu pas

Opt pași de la definire la monitorizare. Tratați‑i ca referință, nu ca o secvență strictă — multe se pot rula în paralel.

  1. Definiți fluxul de automatizare

    Identificați ce sarcini ar trebui automatizate, ce informații are nevoie aplicația dvs., când trebuie trimisă o comandă, cum sunt prevenite comenzile duplicate, cum se tratează erorile și cum se stochează datele de campanie. Un exemplu concret de scoping: o agenție care gestionează 20 de clienți, fiecare cu 3–5 campanii active, dorește ca noile campanii să genereze automat comenzi pentru o listă scurtă de site‑uri pre-aprobate — însă numai după ce un om aprobă brieful campaniei.

  2. Obțineți acces la BlogDrip API

    Deschideți contul la app.blogdrip.com/settings și mergeți la Setările mele → Acces API pentru a găsi credențialele. Veți vedea două valori: un `x-client-id` și un `x-client-secret`. Secretul este afișat o singură dată când este emis sau rotit, așa că copiați‑l imediat în managerul dvs. de secrete. Accesul necesită cheltuieli minime de €500 pe lună la nivel de cont — comenzile manuale și cele prin API se contabilizează ambele. Accesul API este dezactivat automat dacă pragul nu este atins într‑o lună dată. €500 reprezintă un prag de cheltuială, nu o taxă separată de abonament API.

  3. Citiți documentația API

    Documentația oficială la app.blogdrip.com/api/public/docs/index.html descrie exact endpoint‑urile din namespace‑ul `/api/public/*`, autentificarea (cele două headere menționate mai sus), metodele de request, parametrii necesari, formatele de răspuns (endpoint‑urile de listare încadrează răspunsurile în `{ data, pagination }` cu paginare 0-based `?page=0`), erorile de validare (`{ message }`) și operațiunile de comandă disponibile. Tratați documentația ca sursa autoritativă: dacă un parametru nu este documentat, nu presupuneți că există.

  4. Construiți conexiunea API

    Creați un backend de aplicație care stochează `x-client-id` și `x-client-secret` în siguranță (variabile de mediu, secret manager — niciodată în codul front-end), trimite cereri autentificate cu ambele headere setate, parsează răspunsurile, tratează erorile și scrie loguri structurate pentru fiecare apel outbound. Păstrați clientul API ca un modul mic, bine testat, astfel încât restul aplicației dvs. să nu comunice direct cu BlogDrip.

  5. Implementați plasarea automată a comenzilor de guest post

    Conectați fluxul intern la operațiunile de comandă suportate de BlogDrip. Un flux tipic: se creează o campanie nouă în sistem → se selectează un site (rezolvați `marketSiteId` din endpoint‑urile marketplace) → aplicația pregătește informațiile necesare pentru comandă (titlu, URL, descriere, `categoryId`, `marketSiteId`, `campaignId`, `scheduleDate` opțional, `linkNoFollow`) → backend‑ul validează comanda față de regulile dvs. de business → aplicația trimite comanda prin Advertiser API → răspunsul este stocat în sistemul dvs. pentru trasabilitate. Validați fiecare câmp conform spec‑ului OpenAPI înainte de a trimite.

  6. Tratați erorile și comenzile duplicate

    Validați cererile înainte de trimitere, preveniți comenzile duplicate accidentale (o cheie de idempotency sau un control de de‑duplicație server‑side pe partea dvs. sunt patternuri sigure), logați fiecare eșec API cu context suficient pentru depanare ulterioară, gestionați elegant problemele temporare de conectivitate și respectați orice limite de rată documentate. O regulă de reținut: nu retrimiteți automat o cerere de creare a unei comenzi non‑idempotente fără confirmare explicită umană sau de sistem — un retry după o comandă care a fost creată cu succes dar pentru care nu ați văzut răspunsul generează o dublă taxare.

  7. Testați integrarea

    Rulați integrarea împotriva unui mediu sandbox dacă unul este documentat. Dacă nu există sandbox, testați cu atenție în producție — nu rulați suite automate de testare care creează comenzi plătite reale fără autorizare explicită. Folosiți o campanie de test dedicată cu revizuire umană înainte de prima comandă automată și limitați rulările automate de test la o listă scurtă de site‑uri pe care le‑ați preaprobat pentru testare.

  8. Dezvoltați și monitorizați

    Mutați credențialele în magazinul de secrete de producție, adăugați monitorizare pentru erori de integrare și tipare neobișnuite de trimitere a comenzilor, urmăriți rezultatele trimiterii comenzilor end‑to‑end, păstrați logurile operaționale suficient de mult pentru a depana un incident vechi de două săptămâni, monitorizați cheltuielile contului ca să nu pierdeți accesul API dacă scădeți sub pragul lunar de €500 și urmăriți changelog‑ul BlogDrip pentru actualizări API care pot necesita întreținerea integrării.

Modele de integrare

Cum arată o integrare sănătoasă

Sursa autoritativă pentru exemple executabile este specificația OpenAPI la app.blogdrip.com/api/public/openapi.json și documentația lizibilă la /api/public/docs. Spec‑ul este ceea ce ar trebui să folosească codul dvs. pentru a fi generat sau verificat — nu un fragment de pe pagina de prezentare care poate deveni învechit.

În practică, o integrare curată urmează aceeași formă: un modul client API subțire în limbajul preferat — o funcție wrapper per operațiune necesară — se ocupă de mecanică: setează headerele `x-client-id` și `x-client-secret` la fiecare cerere, serialisează body‑ul cererii, deserialisează învelişul `{ data, pagination }` la endpoint‑urile de listare (paginare 0‑based) și convertește răspunsurile de eroare (`{ message }`) în excepții pe care logica de business le poate prinde curat. Fiecare wrapper are cel puțin un test care verifică forma documentată, astfel încât o schimbare de schemă se manifestă ca un test eșuat înainte de a ajunge în producție. Abia după ce acel modul este stabil îl legați de restul aplicației — declanșatoare de campanie, cozi de comenzi, lucrători de retry, raportare.

Această secvență păstrează integrarea auditată: clientul API este o suprafață mică, bine testată; tot restul vorbește cu BlogDrip prin el.

Thin API-client module as a stable integration surface

Bune practici

Ce face ca o integrare API să reziste

Pattern‑uri care mențin sistemele automate sănătoase mult după ziua lansării.

  • Idempotență prin proiectare

    Tratați crearea comenzilor ca fiind costisitoare și ireversibilă. De‑duplicați pe partea dvs. înainte ca cererea să fie trimisă — niciodată după.

  • Higiena credențialelor

    Credențialele API trebuie păstrate într‑un secret manager, separate pe mediu. Rotiți‑le la plecare, nu doar la un incident de securitate.

  • Logare structurată

    Fiecare pereche cerere + răspuns primește un correlation ID. Viitorul dvs. care depanează o comandă veche vă va mulțumi prezentului.

  • Clienți conștienți de limitele de rată

    Respectați limitele de rată documentate. Un client care se retrage ordonat scalează mai bine decât unul care retry‑uie agresiv.

  • Intervenție umană

    Protejați primul apel în producție în spatele unei aprobări umane. Extindeți automatizarea numai după ce integrarea s‑a dovedit stabilă.

  • Monitorizarea cheltuielilor

    Notificați când cheltuielile lunare ale contului tind către sau sub €500. Pierderea accesului API la jumătatea unei campanii este dureroasă.

Întrebări frecvente

Pentru cine este BlogDrip API?

Conturi Advertiser care doresc să conecteze propriul software — un dashboard personalizat, o platformă pentru agenții SEO, un CRM intern — la fluxul de comandă pentru guest post din BlogDrip. Utilizatorii tipici sunt agențiile care gestionează campanii la volum, echipele SEO interne care se integrează cu un stack existent și dezvoltatorii care construiesc unelte operaționale pentru un client sau produs specific.

Trebuie să fiu dezvoltator ca să folosesc API‑ul?

Pentru a construi integrarea în sine, da. API‑ul este o interfață programatică — utilizarea lui implică scriere de cod sau colaborare cu un dezvoltator. Dacă doriți beneficiile operaționale fără munca de integrare, interfața marketplace‑ului acoperă aceeași funcționalitate de comandă manual.

Care sunt cerințele de acces?

Un cont activ BlogDrip care cheltuie cel puțin €500 pe lună în total — comenzile manuale și cele prin API se contabilizează ambele pentru prag. Accesul API este dezactivat automat dacă contul cheltuie mai puțin într‑o lună dată. €500 este un prag de volum, nu o taxă separată de abonament API.

Unde găsesc documentația API?

Documentația oficială a API‑ului este publicată la app.blogdrip.com/api/public/docs/index.html, iar specificația OpenAPI în format machine‑readable este la app.blogdrip.com/api/public/openapi.json. Ambele descriu schema de autentificare, catalogul complet de endpoint‑uri din namespace‑ul `/api/public/*`, formele de request și response, formatul de paginare și răspunsurile de eroare. Tratați‑le ca sursa de adevăr pentru integrarea dvs.

Unde îmi găsesc credențialele API?

În Setările mele → Acces API la app.blogdrip.com/settings. Veți primi un `x-client-id` și un `x-client-secret`; ambele trebuie trimise în fiecare cerere autentificată ca headere HTTP. Secretul este afișat o singură dată când este emis sau rotit — copiați‑l imediat în managerul de secrete, deoarece nu poate fi recuperat ulterior. Credențialele sunt pe cont; tratați‑le ca orice alt secret și păstrați‑le în afara controlului versiunilor.

Cum funcționează paginarea la endpoint‑urile de listare?

Endpoint‑urile de listare încadrează răspunsurile într‑un înveliş `{ data, pagination }` și folosesc paginare 0‑based — treceți `?page=0` pentru prima pagină, `?page=1` pentru a doua și așa mai departe. Blocul de paginare din răspuns vă spune dacă mai există pagini. Dacă migrați din interfața veche `/api/<path>`, forma răspunsului rămâne neschimbată — doar calea de bază se mută la `/api/public/*`.

API‑ul acceptă webhooks?

Verificați specificația OpenAPI la app.blogdrip.com/api/public/openapi.json pentru lista curentă de mecanisme suportate de callback sau notificare de evenimente. Dacă o funcționalitate nu este listată, construiți integrarea fără a presupune că există — polling‑ul API‑ului la programul dvs. este o opțiune sigură de rezervă.

Există un mediu sandbox?

Răspunsul autoritativ este în documentația API curentă. Dacă un sandbox este listat, folosiți‑l pentru testarea integrării. Dacă nu este listat, nu creați comenzi plătite reale în timpul testelor automate fără autorizare explicită — folosiți în schimb o campanie de test dedicată și revizuire umană.

Pot comenzile prin API să folosească Instant Publishing?

Disponibilitatea Instant Publishing depinde de site‑ul selectat și de existența unei integrări de publicare automată suportate (fie pluginul BlogDrip pentru WordPress, fie o conexiune Agency API). Orice comandă — API sau manuală — plasată pe un site eligibil poate beneficia de publicare automatizată. Nu toate site‑urile din marketplace oferă această opțiune, așa că integrarea dvs. ar trebui să trateze timpul de publicare ca specific fiecărui site, nu uniform.

Care e diferența între Advertiser API și Agency API?

Advertiser API este pentru clienții care vor să automatizeze plasarea comenzilor de guest post din propriul software. Agency API este pentru agenții externe, platforme de link building și rețele de publisheri care vor să conecteze propriul inventar la BlogDrip și să automatizeze fulfillment‑ul suportat. Ambele sunt independente — utilizarea unuia nu impune utilizarea celuilalt.

Ce se întâmplă dacă retrimit o cerere de creare a unei comenzi eșuate?

Dacă nu ați văzut un răspuns confirmat, presupuneți că prima cerere s‑ar fi putut finaliza pe server. Nu retrimiteți automat crearea unei comenzi non‑idempotente. Adăugați o cheie de de‑duplicație server‑side sau interogați pentru comanda posibil creată înainte de a retrimite — orice metodă pe care fluxul dvs. o susține curat. Retry‑ul pe o comandă creată cu succes dar a cărei răspuns nu a fost văzut generează o dublă taxare.

Gata să automatizați link building‑ul?

Deschideți documentația API, generați credențialele și începeți dezvoltarea. Marketplace‑ul scalează cu automatizarea dvs. — nu invers.