Antes de prometerle a un cliente «eso lo integramos por API», conviene saber qué permite de verdad la API de GoHighLevel y, sobre todo, qué no. La documentación oficial lista endpoints; lo que no te dice es cuáles familias son sólidas, cuáles tienen trampas y qué cosas que parecen obvias simplemente no se pueden hacer por API. Este artículo es ese mapa, construido desde una integración propia en producción que expone más de 150 operaciones de la API y las ejercita a diario.
La respuesta corta es que la API v2 cubre casi todo el plano de los DATOS (contactos, conversaciones, oportunidades, citas, pagos) y casi nada del plano de la CONSTRUCCIÓN (workflows, funnels, formularios se crean solo desde la interfaz). Esa línea divide lo que puedes automatizar desde fuera y lo que siempre requerirá clics. Vamos por partes.
Respuesta rápida
- Dos generaciones: la API v1 está obsoleta; todo lo nuevo va sobre la v2 (services.leadconnectorhq.com) con el header
Versionobligatorio. - Autenticación: Private Integration Token (PIT) para integraciones propias; OAuth para apps de marketplace. La API key clásica de v1 está en retirada.
- Lo que permite: CRUD completo de contactos, envío de mensajes (SMS, email, WhatsApp), oportunidades, citas, etiquetas, campos personalizados, notas, tareas, facturas, lectura de transacciones e inscripción de contactos en workflows.
- Lo que NO permite: crear o editar workflows, construir funnels o formularios, y el reporting agregado es limitado: eso vive en la interfaz.
- Límites: ráfaga de 100 peticiones por 10 segundos y 200.000 al día por subcuenta y app: suficientes para operar, insuficientes para fuerza bruta.
| Familia | ¿Qué permite? | Nivel |
|---|---|---|
| Contactos | Crear, actualizar, upsert, buscar, etiquetar, campos personalizados | Completo |
| Conversaciones | Leer hilos y enviar SMS, email y WhatsApp | Completo |
| Oportunidades | CRUD y movimiento entre etapas de pipeline | Completo |
| Calendarios | Consultar disponibilidad, crear y gestionar citas | Completo |
| Pagos y facturas | Leer transacciones y órdenes, crear y enviar facturas | Parcial (lectura fuerte) |
| Workflows | Inscribir y retirar contactos. Nada más | Solo gatillo |
| Funnels y formularios | Leer estructura y capturas. No se construyen | Solo lectura |
| Agencia | Crear subcuentas, usuarios, cargar snapshots, SaaS | Avanzado (Agency Pro) |
La tabla ya insinúa el patrón: datos sí, construcción no. Esa es la frontera que define qué proyectos son viables.
¿Qué permite la API de GoHighLevel?
La API v2 de GoHighLevel permite crear y actualizar contactos, enviar mensajes por SMS, email y WhatsApp, gestionar oportunidades, citas, etiquetas, campos personalizados, facturas y pagos, e inscribir contactos en workflows. No permite crear ni editar workflows, funnels o formularios: la construcción de automatizaciones solo existe en la interfaz.
Tiempos reales para dimensionar un proyecto de integración:
- Integración de lectura (dashboards, respaldos, reportes propios): 1 a 2 jornadas.
- Integración bidireccional con escritura idempotente: 3 a 5 jornadas.
- Producto sobre la API (portal de cliente, sincronizador, MCP): 2 semanas hacia arriba.
El plano de los datos: lo que sí se automatiza
Contactos: la familia más madura
El corazón de la API. Crear, actualizar y buscar contactos funciona bien, con un endpoint de upsert que resuelve el «¿existe ya?» en una sola llamada, clave para integraciones idempotentes. Las etiquetas y los campos personalizados se manejan por API, lo que habilita el patrón más útil de todos: sistemas externos que escriben su resultado en un custom field y dejan que un workflow interno reaccione. Sobre esta familia montamos desde respaldos automáticos de contactos hasta sincronizaciones completas con bases externas.
Conversaciones y mensajes: el superpoder subestimado
La API permite leer hilos de conversación y enviar mensajes salientes por SMS, email y WhatsApp. Es la base de cualquier bot propio, de las respuestas generadas por IA fuera de la plataforma y de los sistemas de notificación que no caben en un workflow. El matiz operativo: cada canal necesita su configuración previa en la subcuenta (números, dominios de envío, la integración de WhatsApp activa) y la API no te exime de las reglas de cada canal, como las plantillas de Meta en WhatsApp.
Oportunidades, citas, pagos
Las oportunidades se crean y se mueven de etapa por API, lo que permite pipelines alimentados por eventos externos (una compra en tu plataforma mueve la tarjeta sola). Los calendarios exponen disponibilidad y gestión de citas: se pueden construir experiencias de agendamiento propias sin el widget nativo. Y la familia de pagos permite leer transacciones y órdenes y crear facturas, la base de sistemas de reconciliación de pagos que derivan quién está al día desde los hechos y no desde anotaciones manuales.
Nivel agencia: subcuentas y snapshots
Con Agency Pro, que la página de precios asocia al acceso avanzado, la API sube de nivel: crear subcuentas, usuarios y cargar snapshots programáticamente. Es lo que hace posible el onboarding automatizado: el cliente paga, y un proceso crea su subcuenta, carga el snapshot y configura usuarios sin intervención humana. Para agencias con volumen o modelos SaaS, esta familia sola justifica el plan.
El plano de la construcción: lo que NO se puede hacer
La lista que ahorra proyectos fallidos. Por API no se puede: crear o editar workflows (solo inscribir y retirar contactos de los existentes), construir funnels o páginas, crear formularios o encuestas, ni configurar la mayoría de ajustes de subcuenta. El reporting agregado también es limitado: las métricas que ves en los dashboards nativos no siempre existen como endpoint, y los reportes serios se construyen leyendo los datos crudos y agregándolos fuera.
La consecuencia práctica: cualquier proyecto que prometa «replicar automatizaciones entre cuentas por API» o «generar funnels programáticamente» va a chocar con la plataforma. Para eso existen los snapshots, que empaquetan construcción, y la API los carga. Es la vía correcta: construir una vez en la interfaz, replicar por snapshot, operar los datos por API.
Autenticación, límites y el terreno real
Para integraciones propias, el camino es el Private Integration Token: se genera por subcuenta, define scopes y evita el baile de OAuth. Las apps de marketplace usan OAuth completo. En ambos casos, el header Version: 2021-07-28 es obligatorio y su ausencia produce errores poco descriptivos.
Los límites publicados: ráfaga de 100 peticiones por 10 segundos y techo de 200.000 diarias por subcuenta y aplicación. En la práctica, una sincronización bien construida procesa del orden de 8 contactos por segundo respetando límites, lo que significa que 50.000 contactos toman horas, no minutos: los proyectos de migración deben planificarse con esa aritmética. Y el terreno tiene grietas que la documentación no cuenta: familias que identifican la subcuenta de formas distintas, errores 400 donde esperarías 404, paginaciones inconsistentes. Ese mapa de trampas lo documentamos aparte en los errores no documentados de la API, y las decisiones de robustez del lado receptor en la guía de webhooks en producción.
Cuándo NO usar la API
Si lo que necesitas ya lo hace un workflow nativo (etiquetar, mover pipeline, enviar secuencias), la API es complejidad sin retorno: los workflows nativos son más baratos de mantener que cualquier código. Y si tu integración es un conector estándar (formularios, Zapier, n8n con nodos existentes), tampoco: la API directa es para cuando necesitas control fino, volumen o lógica que las herramientas de conexión no expresan. El requisito de plan también cuenta: el uso serio de la API pide Unlimited hacia arriba, y el nivel agencia (subcuentas, snapshots), el plan Pro.
Errores comunes
- Prometer construcción por API: workflows y funnels no se crean programáticamente. Verifica la frontera datos/construcción antes de cotizar un proyecto.
- Ignorar el header Version: es obligatorio en v2 y su ausencia genera errores que no dicen «te falta el header».
- Diseñar sin presupuesto de rate limit: 100 peticiones por 10 segundos se agotan rápido en bucles ingenuos; toda operación masiva necesita throttling y reintentos.
- Construir sobre la v1: está obsoleta; cualquier integración nueva sobre ella nace con fecha de caducidad.
- Asumir que todos los endpoints se comportan igual: la identificación de subcuenta y los códigos de error varían por familia; el cliente HTTP debe encapsular esas diferencias.
Preguntas frecuentes
No tiene costo aparte, pero el nivel depende del plan: la página de precios de GoHighLevel lista el acceso básico a la API en Unlimited (297 USD) y el avanzado en Agency Pro (497 USD), que es el que abre las capacidades de agencia: crear subcuentas, cargar snapshots y SaaS.
No. La API solo permite inscribir y retirar contactos de workflows existentes. Para replicar automatizaciones entre subcuentas, el mecanismo correcto son los snapshots, que sí se cargan por API en el nivel agencia.
Es un token por subcuenta con permisos delimitados, pensado para integraciones propias sin pasar por OAuth. Es la vía recomendada para conectar tus sistemas internos. OAuth queda para apps publicadas en el marketplace que instalan terceros.
Ráfaga de 100 peticiones por 10 segundos y 200.000 peticiones diarias por subcuenta y aplicación. Para operación normal sobran; para migraciones masivas obligan a planificar: decenas de miles de contactos se procesan en horas respetando los límites.
Sí, y suele ser el mejor primer paso: los nodos existentes cubren los casos comunes sin escribir código. La API directa entra cuando necesitas endpoints que los conectores no exponen, control de errores fino o volumen alto. Documentamos ese camino en la guía de integración con n8n.
Mapa verificado contra una integración propia en producción con más de 150 operaciones sobre la API v2, a julio de 2026. Si tienes un proyecto de integración sobre GoHighLevel y quieres evitarte las semanas de prueba y error, este es el tipo de sistema que diseño e implemento.
El criterio final
La API de GoHighLevel es mejor de lo que su documentación sugiere y peor de lo que su marketing implica. Cubre con solvencia todo el plano de los datos, y ahí habilita sistemas reales: bots propios, reconciliación financiera, onboarding automatizado, respaldos. Y tiene una frontera nítida en la construcción, que sigue perteneciendo a la interfaz. Los proyectos que fracasan son casi siempre los que no conocían esa frontera antes de empezar. Los que la conocen diseñan con ella a favor: construyen en la interfaz, replican con snapshots y automatizan los datos por API. Ese reparto de trabajo es toda la arquitectura.
