Utvecklarguide
Bygg ditt eget verktyg för automatiserat länkbyggande med BlogDrip API
Koppla din mjukvara direkt till BlogDrip och automatisera beställningar av gästinlägg. Bygg anpassade SEO-flöden, integrera befintliga verktyg och hantera länkbyggandet mer effektivt.
Varför automatisera
Varför bygga ett eget verktyg för automatiserat länkbyggande
SEO-byråer och interna marknadsteam fastnar i samma operativa mönster: manuellt sökande efter publiceringsmöjligheter, att återregistrera beställningar av gästinlägg, jonglera flera kundkampanjer, överföra information mellan interna system, övervaka orderns status och försöka skala allt detta utan att proportionellt öka personalstyrkan.
En API-integration tar bort det repetitiva mekaniska arbetet från teamets bord och låter koden sköta rutinerna. Din befintliga mjukvara — CRM, kampanjhanteringsverktyg eller en anpassad dashboard där ditt team redan jobbar — kommunicerar direkt med marknadsplatsen. Operatörerna kan fokusera på strategi, briefar och kvalitetskontroll istället för att mata in beställningar.
Automation ger effektivare arbetsflöden, inte bättre SEO-resultat i sig. Det får inte en dålig kampanj att lyckas och ersätter inte mänskligt omdöme vid val av publicerare. Det den är bra på är att ta bort nivåer av dataregistrering, så när du väl bestämt vad som ska köpas kan du utföra det i vilken volym som helst.
Vad du kan bygga
Vad du kan bygga med BlogDrip API
Praktiska mönster för mjukvara byggd ovanpå en programmatisk marknadsplatsintegration.
Anpassad dashboard för gästinlägg
En intern applikation som kopplar till BlogDrip och skickar stödjade beställningar av gästinlägg från ett UI som ditt team kontrollerar.
System för SEO-byråhantering
Beställningar av gästinlägg inbyggt i ett befintligt byråarbetsflöde, så kampanjansvariga aldrig behöver lämna det system de redan använder.
Automatisk orderinlämning
API-förfrågningar skapar stödjade beställningar av gästinlägg i batch, utan det manuella steget att fylla i varje order.
Hantera kundkampanjer
Koppla interna kund- och kampanjregister till BlogDrip:s orderflöden — en enda sanningskälla för vem som köper vad.
Automatisera arbetsflöden
Trigga stödjade API-operationer från interna affärsprocesser — godkännanden, kickoffs eller schemalagda kampanjvågor.
Rapportering och övervakning
Hämta orderrelaterad information till anpassade rapportverktyg där det stöds. Begränsa rapporteringen till vad API:et faktiskt exponerar istället för att anta full realtidsinsyn.
Arkitektur
Exempel på automationsarkitektur
En sund integration separerar ansvar över fyra lager.
Längst upp finns din externa automationsapplikation — en anpassad dashboard, SEO-byråprogramvara, internt CRM eller kampanjhanteringssystem. Det är här ditt team arbetar dag för dag.
Under ligger din applikations backend. Dess ansvar är de saker varje integration måste göra rätt: lagra `x-client-id` och `x-client-secret` säkert, validera input innan den når BlogDrip, förbereda och skicka API-förfrågningar, hantera `{ data, pagination }`-svar, logga operationella händelser och hantera retries säkert så att ett tillfälligt nätverksavbrott inte blir en duplicerad betald order.
Därifrån träffar förfrågningarna BlogDrip Advertiser API — den publika, versionssatta ytan under `/api/public/*` — som exponerar den stödjade funktionaliteten för beställning av gästinlägg.
API:et dirigerar orderna ut i BlogDrip-marknadsplatsen — mer än 275,000+ webbplatser i total inventarie — och därifrån vidare in i tillämpliga orderhanterings- och publiceringsflöden. Beroende på vald webbplats kan publicering ske manuellt hos publiceraren eller automatiseras via WordPress-pluginen eller Agency API. Inte varje webbplats i marknadsplatsen stödjer Instant Publishing, så din integration bör behandla publiceringstidpunkten som beroende av arbetsflödet, inte omedelbar.
Bygg ditt automationsverktyg, steg för steg
Åtta steg från avgränsning till övervakning. Betrakta dem som en referens, inte en strikt ordning — många körs parallellt.
Definiera ditt automationsflöde
Identifiera vilka uppgifter som ska automatiseras, vilken information din applikation behöver, när en order ska skickas, hur duplicerade orders förhindras, hur fel hanteras och hur kampanjdata lagras. Ett konkret scopes-exempel: en byrå som hanterar 20 klienter, vardera med 3–5 aktiva kampanjer, vill att nya kampanjer automatiskt genererar beställningar för en kortlista med förgodkända webbplatser — men bara efter att en människa godkänt kampanjbriefen.
Skaffa åtkomst till BlogDrip API
Öppna ditt konto på app.blogdrip.com/settings och gå till Mina inställningar → API-åtkomst för att hitta dina uppgifter. Du kommer se två värden: ett `x-client-id` och ett `x-client-secret`. Secret visas en gång när den utfärdas eller roteras, så kopiera den till din hemlighetshanterare omedelbart. Åtkomst kräver minst €500 per månad i totalt konto-konsumtion — manuella order räknas, API-order räknas, båda spåren tillsammans. API-åtkomst inaktiveras automatiskt om minimibeloppet inte uppnås under en given månad. €500 är en utgiftsgräns, inte en separat API-prenumerationsavgift.
Läs API-dokumentationen
De officiella docs på app.blogdrip.com/api/public/docs/index.html beskriver exakt vilka endpoints som finns under `/api/public/*`-namnrymden, autentisering (de två headerparen som nämnts ovan), request-metoder, obligatoriska parametrar, svarsformat (list-endpoints kapslar svar i `{ data, pagination }` med 0-baserad `?page=0`), valideringsfel (`{ message }`) och tillgängliga beställningsoperationer. Behandla dokumentationen som auktoritativ källa: om en parameter inte dokumenteras, anta inte att den finns.
Bygg API-anslutningen
Skapa en applikationsbackend som lagrar både `x-client-id` och `x-client-secret` säkert (miljövariabler, secret manager — aldrig i frontend-kod), skickar autentiserade förfrågningar med båda headers satta, parsar svar, hanterar fel och skriver strukturerade loggar för varje utgående anrop. Håll API-klienten som en liten, vältestad modul så resten av applikationen aldrig pratar med BlogDrip direkt.
Implementera automatisk beställning av gästinlägg
Koppla ditt interna arbetsflöde till de stödjade BlogDrip-orderoperationerna. Ett typiskt flöde: en ny kampanj skapas i ditt system → en webbplats väljs (lös ut dess `marketSiteId` från marknadsplatsendpoints) → din applikation förbereder nödvändig orderinformation (titel, URL, beskrivning, `categoryId`, `marketSiteId`, `campaignId`, valfri `scheduleDate`, `linkNoFollow`) → backend validerar ordern mot dina affärsregler → applikationen skickar ordern via Advertiser API → svaret sparas i ditt system för spårbarhet. Validera varje fält mot OpenAPI-specen innan du skickar.
Hantering av fel och duplicerade orders
Validera förfrågningar innan inlämning, förhindra oavsiktliga dubbla orders (en idempotency-nyckel eller en server-side de-duplication-check på din sida är ett säkert mönster), logga varje API-fel med tillräcklig kontext för att felsöka senare, hantera tillfälliga anslutningsproblem graciöst och respektera dokumenterade rate limits. En regel att internalisera: försök aldrig automatiskt igen för en icke-idempotent ordercreation utan uttrycklig mänsklig eller systembekräftelse — en retry på en lyckad order som du inte såg svaret för skapar en dubbeldebitering.
Testa din integration
Kör din integration mot ett sandbox-miljö om en sådan dokumenteras. Om ingen sandbox finns, testa mot produktion försiktigt — kör aldrig automatiska testsuiter som skapar verkliga betalda orders utan uttrycklig auktorisation. Använd en dedikerad testkampanj med en människa i loopen innan den första automatiska ordern skickas, och lås automatiska testruns till en kort whitelist av webbplatser du förgodkänt för integrationstestning.
Driftsätt och övervaka
Flytta credentials till din produktions-hemlighetshanterare, lägg till övervakning för integrationsfel och ovanliga ordermönster, spåra orderinlämning end-to-end, behåll driftloggar tillräckligt länge för att felsöka en incident som är två veckor gammal, övervaka ditt kontos utgifter så du inte förlorar API-åtkomst genom att underskrida €500-månadsminimin och bevaka BlogDrip changelog för API-uppdateringar som kan kräva underhåll av integrationen.
Integrationsmönster
Hur en stabil integration ser ut
Den auktoritativa källan för exekverbara exempel är OpenAPI-specifikationen på app.blogdrip.com/api/public/openapi.json och de läsbara docs på /api/public/docs. Specen är vad din kod bör genereras eller kontrolleras mot — inte ett landningssidautdrag som kan bli inaktuellt.
I praktiken följer en ren integration ofta samma form. En tunn API-klientmodul i ditt föredragna språk — en wrapper-funktion per operation du behöver — hanterar mekaniken: den sätter `x-client-id` och `x-client-secret` headers på varje förfrågan, serialiserar request-body, deserialiserar `{ data, pagination }`-konvolutet på list-endpoints (0-baserad paging) och översätter felrespons (`{ message }`) till undantag som din affärslogik kan fånga snyggt. Varje wrapper har åtminstone ett test som assertingar mot den dokumenterade formen, så en schemaförändring syns som ett felande test innan det når produktion. Först efter att modulen är stabil kopplar du in den i resten av applikationen — kampanjtriggers, orderkösystem, retry-workers, rapportering.
Den sekvensen håller integrationen auditerbar: din API-klient är en liten, vältestad yta; allt annat pratar med BlogDrip genom den.
Bästa praxis
Vad som gör att en API-integration håller
Mönster som håller automatiserade system friska långt efter lansering.
Idempotens från början
Behandla ordercreation som dyrt och oåterkalleligt. Deduplicera på din sida innan förfrågan går ut — aldrig efter.
Hygien för credentials
API-uppgifter hör hemma i en secret manager, scoped per miljö. Rotera dem vid avgång, inte vid en incident.
Strukturerad loggning
Varje request + response-par får ett correlation ID. Framtida du som felsöker en gammal order kommer tacka nutida du.
Rate-limit-aware-klienter
Respektera dokumenterade rate limits. En klient som backar av snyggt skalar längre än en som försöker om igen aggressivt.
Människa i loopen
Skydda det första produktionsanropet bakom ett mänskligt godkännande. Utöka automation först efter att integrationen visat sig stabil.
Övervakning av utgifter
Larma när månatliga kontoutgifter närmar sig eller faller under €500. Att tappa API-åtkomst mitt i en kampanj är smärtsamt.
Vanliga frågor
Vem är BlogDrip API för?
Advertiser-konton som vill koppla sin egen mjukvara — en anpassad dashboard, en SEO-byråplattform eller ett internt CRM — till BlogDrip:s beställningsflöde för gästinlägg. Typiska användare är byråer som hanterar kampanjer i volym, interna SEO-team som integrerar med en befintlig stack och utvecklare som bygger driftverktyg för en specifik klient eller produkt.
Måste jag vara utvecklare för att använda API:et?
För att bygga integrationen själv, ja. API:et är ett programmatisk gränssnitt — att använda det kräver kodning eller samarbete med en utvecklare. Om du vill ha de operativa fördelarna utan integrationsarbetet täcker marknadsplatsens UI samma beställningsfunktionalitet manuellt.
Vad krävs för åtkomst?
Ett aktivt BlogDrip-konto som spenderar minst €500 per månad i totalförbrukning — både manuella och API-order räknas mot tröskeln. API-åtkomst inaktiveras automatiskt om ditt konto spenderar mindre under en given månad. €500 är en volymtröskel, inte en separat API-prenumerationsavgift.
Var finns API-dokumentationen?
Den officiella API-dokumentationen publiceras på app.blogdrip.com/api/public/docs/index.html, med den maskinläsbara OpenAPI-specifikationen på app.blogdrip.com/api/public/openapi.json. Båda beskriver autentiseringsschemat, hela endpointkatalogen under `/api/public/*`-namnrymden, request- och responsformat, pagineringsformat och felresponser. Behandla dem som sanningskällan för din integration.
Var hittar jag mina API-uppgifter?
I Mina inställningar → API-åtkomst på app.blogdrip.com/settings. Du får ett `x-client-id` och ett `x-client-secret`; båda ska skickas i varje autentiserad förfrågan som HTTP-headers. Secret visas en gång när den utfärdas eller roteras — kopiera den till din secret manager direkt, eftersom den inte kan hämtas senare. Uppgifterna är per konto; behandla dem som andra hemligheter och håll dem utanför versionskontroll.
Hur fungerar paginering på list-endpoints?
List-endpoints kapslar sina svar i ett `{ data, pagination }`-konvolut och använder 0-baserad paging — skicka `?page=0` för första sidan, `?page=1` för andra, och så vidare. Pagineringsblocket i svaret talar om ifall fler sidor finns. Om du migrerar från det äldre `/api/<path>`-gränssnittet är svarsskicket oförändrat — endast basvägen flyttar till `/api/public/*`.
Stöder API:et webhooks?
Kontrollera OpenAPI-specen på app.blogdrip.com/api/public/openapi.json för den aktuella listan över stödjade callback- eller händelsenotifieringsmekanismer. Om en funktion inte listas, bygg din integration utan att anta att den finns — polling av API:et med din egen rytm är en säker fallback.
Finns det en sandbox-miljö?
Det auktoritativa svaret finns i den aktuella API-dokumentationen. Om en sandbox anges, använd den för integrationstester. Om ingen finns, skapa inte verkliga betalda orders under automatiserade tester utan uttrycklig auktorisation — använd en dedikerad testkampanj och en människa i loopen istället.
Kan API-order använda Instant Publishing?
Tillgängligheten för Instant Publishing beror på att den valda webbplatsen har en stödjad automatiserad publiceringsintegration (antingen BlogDrip WordPress-plugin eller en Agency API-anslutning). Alla orders — API eller manuella — som läggs på en kompatibel webbplats kan dra nytta av automatiserad publicering. Inte varje webbplats i marknadsplatsen stödjer det, så din integration bör behandla publiceringstidpunkt per webbplats, inte som enhetlig.
Vad är skillnaden mellan Advertiser API och Agency API?
Advertiser API är för kunder som vill automatisera beställning av gästinlägg från sin egen mjukvara. Agency API är för externa byråer, länkbyggnadsplattformar och publicerarnätverk som vill koppla sin egen inventory till BlogDrip och automatisera stödjad fulfillment. Båda är fristående — att använda den ena kräver inte den andra.
Vad händer om jag försöker igen efter en misslyckad order-creation?
Om du inte såg ett bekräftat svar, anta att den första förfrågan kan ha lyckats på serversidan. Försök inte automatiskt igen för icke-idempotent ordercreation. Lägg till en server-side dedupliceringsnyckel, eller fråga efter den eventuellt skapade ordern innan du försöker igen — det som ditt arbetsflöde stödjer på ett säkert sätt. En retry på en redan skapad men osedd order skapar en dubbeldebitering.
Redo att automatisera ditt länkbyggande?
Öppna API-dokumentationen, generera dina uppgifter och börja bygga. Marknadsplatsen skalar med din automation — inte tvärtom.