Developer guide
Build your own link building automation tool with the BlogDrip API
Connect your software directly to BlogDrip and automate guest post ordering. Build custom SEO workflows, integrate your existing applications, and manage link building operations more efficiently.
Why automate
Why build your own link building automation tool
SEO agencies and in-house marketing teams run into the same operational pattern: manually searching for publishing opportunities, re-entering guest post orders, juggling multiple client campaigns, transferring information between internal systems, monitoring order progress, and trying to scale all of this without proportionally scaling headcount.
An API integration takes the repetitive mechanical work off your team's plate and routes it through code. Your existing software — the CRM, campaign-management tool, or custom dashboard your team already lives in — talks directly to the marketplace. Operators stay focused on strategy, briefs, and quality control instead of order entry.
Automation delivers workflow efficiency, not SEO rankings. It will not make a bad campaign succeed, and it will not replace human judgment on publisher selection. What it does well is remove the data-entry layer, so when you decide what to buy you can execute it at any volume.
What you can build
What you can build with the BlogDrip API
Practical patterns for software built on top of a programmatic marketplace integration.
Custom guest posting dashboard
An internal application that connects to BlogDrip and submits supported guest post orders from a UI your team controls.
SEO agency management system
Guest post ordering wired into an existing agency workflow, so campaign managers never leave the system they already use.
Automated order submission
API requests create supported guest post orders in batch, without the per-order manual data entry step.
Client campaign management
Connect internal client and campaign records to BlogDrip ordering workflows — one source of truth for who's buying what.
Workflow automation
Trigger supported API operations from internal business processes — approvals, kickoffs, scheduled campaign waves.
Reporting and monitoring
Pull order-related information into custom reporting tools where supported. Scope the reporting to what the API actually exposes rather than assuming full real-time visibility.
Architecture
Example automation architecture
A healthy integration separates concerns across four layers.
At the top, your external automation application — a custom dashboard, SEO agency software, internal CRM, or campaign management system. This is where your team works day-to-day.
Underneath sits your application backend. Its responsibilities are the ones every integration needs to get right: store `x-client-id` and `x-client-secret` securely, validate input before it ever reaches BlogDrip, prepare and send API requests, handle `{ data, pagination }` responses, log operational events, and manage retries safely so a transient network blip does not turn into a duplicate paid order.
From there, requests hit the BlogDrip Advertiser API — the public, versioned surface under `/api/public/*` — which exposes the supported guest post ordering functionality.
The API routes orders into the BlogDrip marketplace — more than 275,000 websites of total inventory — and from there into the applicable order processing and publishing workflow. Depending on the selected website, publication may be manual on the publisher's side or automated through the WordPress plugin or the Agency API. Not every website in the marketplace supports Instant Publishing, so your integration should treat publication timing as workflow-dependent, not instantaneous.
Build your automation tool, step by step
Eight steps from scoping to monitoring. Treat them as a reference, not a hard sequence — plenty of them run in parallel.
Define your automation workflow
Identify which tasks should be automated, what information your application needs, when an order should be submitted, how duplicate orders are prevented, how errors are handled, and how campaign data is stored. A concrete scoping example: an agency managing 20 clients, each with 3–5 active campaigns, wants new campaigns to automatically generate orders for a shortlist of pre-approved websites — but only after a human approves the campaign brief.
Obtain BlogDrip API access
Open your account at app.blogdrip.com/settings and go to My Settings → API access to find your credentials. You will see two values: an `x-client-id` and an `x-client-secret`. The secret is shown once when it's issued or rotated, so copy it into your secret manager immediately. Access requires a minimum of €500 per month in total account spending — manual orders count, API orders count, both tracks combined. API access is deactivated automatically if the minimum is not met in a given month. The €500 is a spending threshold, not a separate API subscription fee.
Read the API documentation
The official docs at app.blogdrip.com/api/public/docs/index.html describe the exact endpoints under the `/api/public/*` namespace, authentication (the two header pairs mentioned above), request methods, required parameters, response formats (list endpoints wrap responses in `{ data, pagination }` with 0-based `?page=0`), validation errors (`{ message }`), and available ordering operations. Treat the documentation as the authoritative source: if a parameter is not documented, do not assume it exists.
Build the API connection
Create an application backend that stores both the `x-client-id` and the `x-client-secret` securely (environment variables, secret manager — never in frontend code), sends authenticated requests with both headers set, parses responses, handles errors, and writes structured logs for every outgoing call. Keep the API client as a small, well-tested module so the rest of your application never speaks to BlogDrip directly.
Implement automated guest post ordering
Connect your internal workflow to the supported BlogDrip ordering operations. A typical flow: a new campaign is created in your system → a website is selected (resolve its `marketSiteId` from the marketplace endpoints) → your application prepares the required order information (title, URL, description, `categoryId`, `marketSiteId`, `campaignId`, optional `scheduleDate`, `linkNoFollow`) → the backend validates the order against your business rules → the application submits the order through the Advertiser API → the response is stored in your system for traceability. Validate every field against the OpenAPI spec before shipping.
Handle errors and duplicate orders
Validate requests before submission, prevent accidental duplicate orders (an idempotency key or a server-side de-duplication check on your side is a safe pattern), log every API failure with enough context to debug later, handle temporary connectivity problems gracefully, and respect any documented rate limits. One rule to internalise: never automatically retry a non-idempotent order creation request without explicit human or system confirmation — a retry on a successful order you did not see the response for creates a double-charge.
Test your integration
Run your integration against a sandbox environment if one is documented. If no sandbox is available, test against production carefully — never run automated test suites that create real paid orders without explicit authorisation. Use a dedicated test campaign with a human-in-the-loop review before the first automated order ships, and lock automated test runs to a short allow-list of websites you've pre-approved for integration testing.
Deploy and monitor
Move credentials into your production secret store, add monitoring for integration failures and unusual order submission patterns, track order submission results end-to-end, keep operational logs long enough to debug a two-week-old incident, monitor your account spending so you don't lose API access by dropping below the €500 monthly minimum, and watch the BlogDrip changelog for API updates that may require integration maintenance.
Integration patterns
What a healthy integration looks like
The authoritative source for executable examples is the OpenAPI specification at app.blogdrip.com/api/public/openapi.json and the human-readable docs at /api/public/docs. The spec is what your code should be generated or checked against — not a landing-page snippet that could go stale.
In practice, a clean integration tends to follow the same shape. A thin API-client module in your preferred language — one wrapper function per operation you need — handles the mechanics: it sets the `x-client-id` and `x-client-secret` headers on every request, serialises the request body, deserialises the `{ data, pagination }` envelope on list endpoints (0-based paging), and converts error responses (`{ message }`) into exceptions your business logic can catch cleanly. Each wrapper has at least one test asserting on the documented shape, so a schema change surfaces as a failing test before it reaches production. Only after that module is stable do you wire it into the rest of your application — campaign triggers, order queues, retry workers, reporting.
That sequence keeps the integration auditable: your API client is a small, well-tested surface area; everything else talks to BlogDrip through it.
Best practices
What makes an API integration last
Patterns that keep automated systems healthy long after launch day.
Idempotency by design
Treat order creation as expensive and irreversible. Deduplicate on your side before the request goes out — never after.
Credential hygiene
API credentials belong in a secret manager, scoped per environment. Rotate them on departure, not on breach.
Structured logging
Every request + response pair gets a correlation ID. Future-you debugging a stale order will thank present-you.
Rate-limit-aware clients
Respect the documented rate limits. A client that backs off cleanly scales further than one that retries aggressively.
Human in the loop
Guard the first production call behind a human approval. Expand automation only after the integration has proven stable.
Spend monitoring
Alert when monthly account spend trends toward or beneath €500. Losing API access midway through a campaign is painful.
Frequently asked questions
Who is the BlogDrip API for?
Advertiser accounts that want to connect their own software — a custom dashboard, an SEO agency platform, an internal CRM — to BlogDrip's guest post ordering workflow. Typical users are agencies managing campaigns at volume, in-house SEO teams integrating with an existing stack, and developers building operational tools for a specific client or product.
Do I need to be a developer to use the API?
To build the integration itself, yes. The API is a programmatic interface — using it requires writing code or working with a developer. If you want the operational benefits without the integration work, the marketplace UI covers the same ordering functionality manually.
What are the access requirements?
An active BlogDrip account that spends at least €500 per month in total — manual and API orders both count toward the threshold. API access is deactivated automatically if your account spends less in a given month. The €500 is a volume threshold, not a separate API subscription fee.
Where is the API documentation?
The official API documentation is published at app.blogdrip.com/api/public/docs/index.html, with the machine-readable OpenAPI specification at app.blogdrip.com/api/public/openapi.json. Both describe the authentication scheme, the full endpoint catalogue under the `/api/public/*` namespace, request and response shapes, pagination format, and error responses. Treat them as the source of truth for your integration.
Where do I find my API credentials?
In My Settings → API access at app.blogdrip.com/settings. You'll get an `x-client-id` and an `x-client-secret`; both go into every authenticated request as HTTP headers. The secret is shown once when it's issued or rotated — copy it into your secret manager immediately, as it cannot be retrieved later. Credentials are per-account; treat them like any other secret and keep them out of version control.
How does pagination work on list endpoints?
List endpoints wrap their responses in a `{ data, pagination }` envelope and use 0-based paging — pass `?page=0` for the first page, `?page=1` for the second, and so on. The pagination block in the response tells you whether more pages exist. If you're migrating from the legacy `/api/<path>` interface, the response shape is unchanged — only the base path moves to `/api/public/*`.
Does the API support webhooks?
Check the OpenAPI spec at app.blogdrip.com/api/public/openapi.json for the current list of supported callback or event-notification mechanisms. If a feature isn't listed, build your integration without assuming it exists — polling the API on your own schedule is a safe fallback.
Is there a sandbox environment?
The authoritative answer is in the current API documentation. If a sandbox is listed, use it for integration testing. If one is not listed, do not create real paid orders during automated testing without explicit authorisation — use a dedicated test campaign and human-in-the-loop review instead.
Can API orders use Instant Publishing?
Instant Publishing availability depends on the selected website having a supported automated publishing integration (either the BlogDrip WordPress plugin or an Agency API connection). Any order — API or manual — placed on an eligible website can benefit from automated publication. Not every website in the marketplace supports it, so your integration should treat publication timing as per-website, not uniform.
What is the difference between the Advertiser API and the Agency API?
The Advertiser API is for customers who want to automate guest post ordering from their own software. The Agency API is for external agencies, link building platforms, and publisher networks that want to connect their own inventory to BlogDrip and automate supported fulfillment. Both are standalone — using one does not require the other.
What happens if I retry a failed order creation request?
If you did not see a confirmed response, assume the first request may have succeeded on the server side. Do not automatically retry non-idempotent order creation. Add a server-side de-duplication key, or query for the possibly-created order before retrying — whichever your workflow supports cleanly. A retry on a successful-but-unseen order creates a double-charge.
Ready to automate your link building?
Open the API documentation, generate your credentials, and start building. The marketplace scales with your automation — not the other way around.