Skip to content
Buscar

Guía para desarrolladores

Cree su propia herramienta de automatización de construcción de enlaces con la API de BlogDrip

Conecte su software directamente a BlogDrip y automatice el pedido de posts de invitado. Cree flujos SEO personalizados, integre sus aplicaciones existentes y gestione las operaciones de construcción de enlaces con mayor eficiencia.

Por qué automatizar

Por qué crear su propia herramienta de automatización de construcción de enlaces

Las agencias de SEO y los equipos de marketing internos se encuentran con el mismo patrón operativo: buscar manualmente oportunidades de publicación, volver a introducir pedidos de post de invitado, gestionar múltiples campañas de clientes, transferir información entre sistemas internos, supervisar el progreso de los pedidos y tratar de escalar todo esto sin aumentar proporcionalmente la plantilla.

Una integración mediante API quita el trabajo mecánico repetitivo del equipo y lo encamina a través de código. Su software existente —el CRM, la herramienta de gestión de campañas o el panel personalizado donde su equipo ya trabaja— se comunica directamente con el marketplace. Los operadores se concentran en la estrategia, los briefs y el control de calidad en lugar de en la entrada de pedidos.

La automatización aporta eficiencia en los flujos de trabajo, no posiciones en buscadores. No hará que una campaña mala funcione, ni sustituirá el juicio humano a la hora de seleccionar publicadores. Lo que sí hace bien es eliminar la capa de entrada de datos, de modo que cuando usted decida qué comprar pueda ejecutarlo a cualquier escala.

SEO team automating repetitive link building tasks

Qué puede construir

Qué puede construir con la API de BlogDrip

Patrones prácticos para software construido sobre una integración programática con el marketplace.

  • Panel personalizado para posts de invitado

    Una aplicación interna que se conecta a BlogDrip y envía órdenes de post de invitado compatibles desde una interfaz que su equipo controla.

  • Sistema de gestión para agencias SEO

    Pedidos de post de invitado integrados en el flujo de trabajo de la agencia existente, para que los gestores de campaña nunca salgan del sistema que ya usan.

  • Envío automatizado de órdenes

    Solicitudes a la API que crean órdenes de post de invitado compatibles en lote, sin el paso manual por pedido.

  • Gestión de campañas de clientes

    Conecte los registros internos de clientes y campañas con los flujos de pedido de BlogDrip —una única fuente de verdad sobre quién compra qué.

  • Automatización de flujos de trabajo

    Dispare operaciones soportadas por la API desde procesos internos —aprobaciones, lanzamientos, oleadas de campaña programadas.

  • Informes y monitorización

    Extraiga información relacionada con pedidos a herramientas de informes personalizadas cuando esté soportado. Limite el alcance del informe a lo que la API realmente expone en lugar de asumir visibilidad en tiempo real completa.

Arquitectura

Arquitectura de ejemplo para automatización

Una integración saludable separa responsabilidades en cuatro capas.

En la parte superior, su aplicación de automatización externa —un panel personalizado, software para agencias SEO, CRM interno o sistema de gestión de campañas. Aquí es donde su equipo trabaja a diario.

Debajo está el backend de su aplicación. Sus responsabilidades son las que toda integración debe resolver: almacenar `x-client-id` y `x-client-secret` de forma segura, validar la entrada antes de que llegue a BlogDrip, preparar y enviar solicitudes a la API, manejar respuestas `{ data, pagination }`, registrar eventos operativos y gestionar reintentos de forma segura para que un fallo de red transitorio no se convierta en un pedido pagado duplicado.

A partir de ahí, las solicitudes llegan al Advertiser API de BlogDrip —la superficie pública y versionada bajo `/api/public/*`— que expone la funcionalidad soportada para pedir posts de invitado.

La API enruta los pedidos hacia el marketplace de BlogDrip —más de 275,000 sitios web de inventario total— y desde ahí hacia el flujo de procesamiento de pedidos y publicación aplicable. Dependiendo del sitio seleccionado, la publicación puede ser manual por parte del publicador o automatizada mediante el plugin de WordPress o el Agency API. No todos los sitios del marketplace soportan Publicación Instantánea, así que su integración debe tratar el tiempo de publicación como dependiente del flujo de trabajo, no como instantáneo.

Four-layer architecture connecting an automation application to BlogDrip

Cree su herramienta de automatización, paso a paso

Ocho pasos desde el alcance hasta la monitorización. Considérelos como referencia, no como una secuencia rígida —muchos se ejecutan en paralelo.

  1. Defina su flujo de automatización

    Identifique qué tareas deben automatizarse, qué información necesita su aplicación, cuándo debe enviarse un pedido, cómo se evitan pedidos duplicados, cómo se gestionan los errores y cómo se almacenan los datos de la campaña. Un ejemplo de alcance concreto: una agencia que gestiona 20 clientes, cada uno con 3–5 campañas activas, quiere que las nuevas campañas generen automáticamente órdenes para una lista corta de sitios preaprobados —pero solo después de que un humano apruebe el brief de la campaña.

  2. Obtenga acceso a la API de BlogDrip

    Abra su cuenta en app.blogdrip.com/settings y vaya a My Settings → API access para encontrar sus credenciales. Verá dos valores: un `x-client-id` y un `x-client-secret`. El secret se muestra una sola vez cuando se emite o rota, así que cópielo inmediatamente en su gestor de secretos. El acceso requiere un gasto mínimo de €500 al mes en el total de la cuenta —los pedidos manuales cuentan, los pedidos por API cuentan, ambos tracks combinados. El acceso a la API se desactiva automáticamente si no se alcanza el mínimo en un mes determinado. Los €500 son un umbral de gasto, no una cuota de suscripción separada para la API.

  3. Lea la documentación de la API

    La documentación oficial en app.blogdrip.com/api/public/docs/index.html describe los endpoints exactos bajo el espacio de nombres `/api/public/*`, la autenticación (los dos pares de cabeceras mencionados arriba), los métodos de solicitud, los parámetros obligatorios, los formatos de respuesta (los endpoints de lista envuelven las respuestas en `{ data, pagination }` con paginación 0-based `?page=0`), los errores de validación (`{ message }`) y las operaciones de pedido disponibles. Trate la documentación como la fuente autorizada: si un parámetro no está documentado, no asuma que existe.

  4. Construya la conexión con la API

    Cree un backend de aplicación que almacene de forma segura tanto `x-client-id` como `x-client-secret` (variables de entorno, gestor de secretos —nunca en código frontend), envíe solicitudes autenticadas con ambas cabeceras, analice las respuestas, maneje errores y escriba logs estructurados para cada llamada saliente. Mantenga el cliente de la API como un módulo pequeño y bien probado para que el resto de su aplicación nunca hable con BlogDrip directamente.

  5. Implemente el pedido automatizado de posts de invitado

    Conecte su flujo de trabajo interno con las operaciones de pedido soportadas por BlogDrip. Un flujo típico: se crea una nueva campaña en su sistema → se selecciona un sitio web (resuelva su `marketSiteId` a partir de los endpoints del marketplace) → su aplicación prepara la información de pedido requerida (título, URL, descripción, `categoryId`, `marketSiteId`, `campaignId`, `scheduleDate` opcional, `linkNoFollow`) → el backend valida el pedido según sus reglas de negocio → la aplicación envía el pedido a través del Advertiser API → la respuesta se almacena en su sistema para trazabilidad. Valide cada campo frente a la especificación OpenAPI antes de enviar.

  6. Gestione errores y pedidos duplicados

    Valide las solicitudes antes del envío, evite pedidos duplicados accidentales (una clave de idempotencia o una comprobación de deduplicación en el servidor por su parte es un patrón seguro), registre cada fallo de la API con suficiente contexto para depurarlo después, gestione problemas temporales de conectividad con gracia y respete cualquier límite de tasa documentado. Una regla a interiorizar: nunca reintente automáticamente una solicitud de creación de pedido no idempotente sin confirmación explícita humana o del sistema —un reintento sobre un pedido que en realidad se creó genera un doble cargo.

  7. Pruebe su integración

    Ejecute su integración contra un entorno sandbox si está documentado. Si no hay sandbox disponible, pruebe contra producción con cuidado —nunca ejecute suites de prueba automatizadas que creen pedidos reales pagados sin autorización explícita. Use una campaña de prueba dedicada con revisión humana antes del primer pedido automatizado y limite las pruebas automatizadas a una lista corta de sitios que haya preaprobado para pruebas de integración.

  8. Despliegue y monitorice

    Traslade las credenciales a su almacén de secretos de producción, añada monitorización para fallos de integración y patrones inusuales de envío de pedidos, haga seguimiento de los resultados de envío de pedidos de extremo a extremo, conserve los logs operativos el tiempo suficiente para depurar un incidente de hace dos semanas, supervise el gasto de su cuenta para no perder acceso a la API por caer por debajo del mínimo mensual de €500 y vigile el changelog de BlogDrip por actualizaciones de la API que puedan requerir mantenimiento de la integración.

Patrones de integración

Cómo es una integración saludable

La fuente autorizada para ejemplos ejecutables es la especificación OpenAPI en app.blogdrip.com/api/public/openapi.json y la documentación legible en /api/public/docs. La spec es contra la que su código debe generarse o verificarse —no un fragmento de landing page que pueda quedar obsoleto.

En la práctica, una integración limpia suele seguir la misma forma. Un módulo cliente de la API delgado en su lenguaje preferido —una función wrapper por operación necesaria— gestiona la mecánica: establece las cabeceras `x-client-id` y `x-client-secret` en cada solicitud, serializa el body de la petición, deserializa el sobre `{ data, pagination }` en endpoints de lista (paginación 0-based) y convierte respuestas de error (`{ message }`) en excepciones que su lógica de negocio pueda capturar claramente. Cada wrapper tiene al menos una prueba que aserta sobre la forma documentada, de modo que un cambio de esquema aparece como una prueba fallida antes de llegar a producción. Solo después de que ese módulo sea estable lo conecta al resto de su aplicación —disparadores de campaña, colas de pedidos, workers de reintento, informes.

Esa secuencia mantiene la integración auditable: su cliente de API es una superficie pequeña y bien probada; todo lo demás habla con BlogDrip a través de él.

Thin API-client module as a stable integration surface

Buenas prácticas

Qué hace que una integración de API perdure

Patrones que mantienen los sistemas automatizados saludables mucho después del lanzamiento.

  • Idempotencia por diseño

    Trate la creación de pedidos como costosa e irreversible. Desduplique en su lado antes de que salga la solicitud —nunca después.

  • Higiene de credenciales

    Las credenciales de la API deben estar en un gestor de secretos, con ámbito por entorno. Rótelas al salir alguien, no solo cuando haya una brecha.

  • Registro estructurado

    Cada par solicitud + respuesta tiene un ID de correlación. El usted del futuro que depure un pedido antiguo le agradecerá al usted presente.

  • Clientes conscientes de límites de tasa

    Respete los límites de tasa documentados. Un cliente que retrocede limpiamente escala más que uno que reintenta agresivamente.

  • Humano en el bucle

    Proteja la primera llamada en producción con una aprobación humana. Expanda la automatización solo después de que la integración haya demostrado estabilidad.

  • Monitorización de gasto

    Alerte cuando el gasto mensual de la cuenta tienda a acercarse o caer por debajo de €500. Perder acceso a la API a mitad de una campaña es doloroso.

Preguntas frecuentes

¿Para quién es la API de BlogDrip?

Cuentas anunciantes que desean conectar su propio software —un panel personalizado, una plataforma para agencias SEO, un CRM interno— con el flujo de pedidos de posts de invitado de BlogDrip. Los usuarios típicos son agencias que gestionan campañas a volumen, equipos SEO internos que integran con una pila existente y desarrolladores que crean herramientas operativas para un cliente o producto específico.

¿Necesito ser desarrollador para usar la API?

Para construir la integración en sí, sí. La API es una interfaz programática —usarla requiere escribir código o trabajar con un desarrollador. Si desea los beneficios operativos sin el trabajo de integración, la interfaz del marketplace cubre la misma funcionalidad de pedidos de forma manual.

¿Cuáles son los requisitos de acceso?

Una cuenta activa de BlogDrip que gaste al menos €500 al mes en total —los pedidos manuales y por API cuentan para el umbral. El acceso a la API se desactiva automáticamente si su cuenta gasta menos en un mes determinado. Los €500 son un umbral de volumen, no una cuota de suscripción separada para la API.

¿Dónde está la documentación de la API?

La documentación oficial de la API está publicada en app.blogdrip.com/api/public/docs/index.html, con la especificación OpenAPI legible por máquina en app.blogdrip.com/api/public/openapi.json. Ambas describen el esquema de autenticación, el catálogo completo de endpoints bajo el espacio de nombres `/api/public/*`, las formas de solicitud y respuesta, el formato de paginación y las respuestas de error. Considérelas la fuente de verdad para su integración.

¿Dónde encuentro mis credenciales de la API?

En My Settings → API access en app.blogdrip.com/settings. Obtendrá un `x-client-id` y un `x-client-secret`; ambos deben incluirse en cada solicitud autenticada como cabeceras HTTP. El secret se muestra una vez cuando se emite o rota —cópielo en su gestor de secretos de inmediato, ya que no puede recuperarse más tarde. Las credenciales son por cuenta; trátelas como cualquier otro secreto y manténgalas fuera del control de versiones.

¿Cómo funciona la paginación en los endpoints de lista?

Los endpoints de lista envuelven sus respuestas en un sobre `{ data, pagination }` y usan paginación 0-based —pase `?page=0` para la primera página, `?page=1` para la segunda, etc. El bloque de paginación en la respuesta le indica si existen más páginas. Si está migrando desde la interfaz legacy `/api/<path>`, la forma de la respuesta no cambia —solo la ruta base se mueve a `/api/public/*`.

¿La API soporta webhooks?

Consulte la spec OpenAPI en app.blogdrip.com/api/public/openapi.json para la lista actual de mecanismos de callback o notificación de eventos soportados. Si una funcionalidad no aparece listada, construya su integración sin asumir que existe —el polling de la API a su propio ritmo es una alternativa segura.

¿Existe un entorno sandbox?

La respuesta autorizada está en la documentación actual de la API. Si aparece un sandbox, úselo para pruebas de integración. Si no aparece, no cree pedidos reales pagados durante pruebas automatizadas sin autorización explícita —utilice una campaña de prueba dedicada y revisión humana en su lugar.

¿Los pedidos por API pueden usar Publicación Instantánea?

La disponibilidad de Publicación Instantánea depende de que el sitio seleccionado tenga una integración de publicación automatizada soportada (ya sea el plugin de BlogDrip para WordPress o una conexión Agency API). Cualquier pedido —API o manual— realizado en un sitio elegible puede beneficiarse de la publicación automatizada. No todos los sitios del marketplace lo soportan, de modo que su integración debe tratar el tiempo de publicación por sitio, no como algo uniforme.

¿Cuál es la diferencia entre el Advertiser API y el Agency API?

El Advertiser API es para clientes que desean automatizar el pedido de posts de invitado desde su propio software. El Agency API es para agencias externas, plataformas de construcción de enlaces y redes de publicadores que quieren conectar su propio inventario a BlogDrip y automatizar el cumplimiento soportado. Ambos son independientes —usar uno no requiere el otro.

¿Qué sucede si reintento una solicitud de creación de pedido que falló?

Si no vio una respuesta confirmada, asuma que la primera solicitud puede haber tenido éxito en el servidor. No reintente automáticamente la creación de pedidos no idempotentes. Añada una clave de deduplicación en el servidor o consulte si el pedido posiblemente creado existe antes de reintentar —lo que su flujo de trabajo soporte limpiamente. Un reintento sobre un pedido que ya se creó pero no vio genera un doble cargo.

¿Listo para automatizar su construcción de enlaces?

Abra la documentación de la API, genere sus credenciales y empiece a construir. El marketplace escala con su automatización —no al revés.