La API
No hay ningún endpoint privado. Ni siquiera para la interfaz.
La mayoría de los productos tienen dos APIs: la documentada que te ofrecen y la interesante que usan sus propias pantallas. La segunda siempre es mejor, y nunca te dejan acercarte a ella. Aquí solo hay una, y la interfaz es un cliente de ella como cualquier otra — lo cual es una restricción para nosotros, y la razón por la que todo lo que quieres construir es posible.
Lo que esa regla cuesta en realidad
Significa que una pantalla a veces tiene que esperar a que la API sea correcta, en lugar de saltársela para obtener un campo cómodo. El día que una pantalla necesite algo que la API pública no puede darle es el día en que la API está mal, y la solución es la API.
La ventaja es que tres clientes muy distintos no cuestan casi nada extra. El servidor MCP es un cliente. Un tile de dash-b es un cliente. Tu propio script es un cliente. Ninguno es un ciudadano de segunda clase que sortee una superficie diseñada para otra persona, porque no hay otra superficie de la que ser segundo.
Documentada y ejercitada
OpenAPI se genera en /docs y cada ruta tiene una prueba que es el ejemplo de la documentación. La documentación escrita por separado del código se desvía en un mes; la documentación que rompe la compilación cuando está mal, no.
Inicio de sesión
Tu cuenta de castomo, mediante el flujo de código de autorización con PKCE — la misma cuenta que usas para dash-b y el resto de la familia. Una página sin servidor propio ejecuta ese flujo perfectamente; es para lo que se diseñó. Para trabajo de máquina a máquina, una clave de API con ámbito de proyecto.
- 1Personas
/v1/contacts·/lists·/segments·/tags·/imports - 2Contenido
/v1/creatives, con validación, vista previa y render por objetivo - 3Automatización
/v1/funnels·/funnels/:id/versions·/runs·/simulate - 4Radiodifusión
/v1/campaigns, con audiencia, materialización, programación y envío como pasos distintos - 5Eventos entrantes
/v1/events— los eventos de tu propia aplicación, como disparadores - 6Entrega
/sender-identities·/domains·/apps·/webhooks - 7Números
/v1/reports/*, y/track/*en el host de seguimiento
OpenAPI en /docs/mcp en el mismo proceso
Convenciones
La misma forma que cualquier otro servicio de castomo
Lo cual importa más de lo que parece. Si ya llamas a uno de estos, ya sabes cómo este responde, falla y pagina.
Un solo sobre de error
Cada fallo tiene la misma forma, un código estable y un mensaje pensado para una persona. Ninguna ruta inventa su propia manera de estar descontenta.
Paginación por cursor
No desplazamientos. Una lista que cambia mientras la recorres no salta ni repite filas en silencio, cosa que la paginación por desplazamiento hace callada y constantemente.
Claves de idempotencia
En cada ruta de modificación. Reintenta una petición que no estás seguro de que llegó y obtén la misma respuesta en lugar de un segundo contacto, una segunda campaña o un segundo envío.
Con ámbito de proyecto
Un token dirige un tenant y un proyecto, ambos. La seguridad a nivel de fila se aplica en la propia base de datos, no dependiendo de que recuerdes añadir una cláusula.
Webhooks salientes
Firmados, reintentados con backoff y entregados al menos una vez — así que tu endpoint también debería ser idempotente. Los eventos usan el mismo vocabulario que los informes.
Borrado y exportación
Un contacto puede exportarse o borrarse a través de la API, y un borrado llega a cada servicio hermano que tuviera una copia a través del canal interno de la familia.
Todo lo que la interfaz puede hacer, un POST puede hacerlo.
Los eventos son la parte interesante
Todo lo demás en esta página es fontanería que esperarías. POST /v1/events es la ruta que cambia para qué sirve el producto.
Tu aplicación ya sabe cosas que ninguna herramienta de marketing puede observar: quién terminó el onboarding, quién invitó a un colega, quién alcanzó un límite, quién exportó sus datos un domingo por la tarde. Publícalos como eventos con tu propio token, y cada uno se convierte en un disparador, una condición y un segmento.
El resto se deriva del modelo de contacto. Los eventos se añaden, nunca se editan; son el registro del que cuelga todo el producto. Un embudo que se dispara con un evento que tú definiste no es una integración — es el mismo mecanismo que usa message_opened, con otro nombre dentro.
- 1Tú lo publicas
POST /v1/events— un nombre, un contacto, un payload, una clave de idempotencia. - 2LlegaSe añade al registro del contacto. Nada más necesita saber que existe.
- 3Se inicia un embudoCualquier embudo cuya entrada nombre ese evento, para cualquier contacto elegible según su especificación de entrada.
- 4Otros embudos se ramifican por él«¿Ha ocurrido este evento en los últimos 14 días?» es un predicado de segmento ordinario.
- iY termina ejecucionesUn nodo de objetivo que nombre el mismo evento detiene una secuencia en el momento en que la persona hace la cosa.
Tu vocabularioTu token
Límites que conviene conocer antes de construir
ClickSomo almacena tres identificadores sobre ti — un tenant, un proyecto y un usuario, como ids opacos — y nada más. Sin contraseña, sin perfil, sin tarjeta, sin factura. Los límites del plan llegan como números: cuántos contactos, cuántos envíos, cuántas generaciones. El vocabulario de pagos no cruza esa línea en ninguna dirección.
Tus contactos son tuyos. Tú eres el responsable del tratamiento; nosotros somos el encargado. No existe ninguna ruta por la que otro producto de la familia pueda leer o escribir tu lista de contactos, ni ningún canal de ingesta que pueda usar.
Si lo estás evaluando en serio: lee /docs antes de seguir leyendo esta web. La API es la descripción honesta de lo que hace el producto, y cada afirmación en estas páginas corresponde a una ruta o a un tipo de nodo que puedes encontrar allí. Cuando el esquema cambia, estas páginas cambian.