No una pestaña de integraciones acoplada — el motor mismo.
La mayoría de los CRMs exponen una API delgada y rezagada junto al producto “real”. La app web de GENECRM, la app móvil y la API son tres clientes de un único backend — así que la API nunca puede quedarse atrás de lo que ves en pantalla.
Nada en la app queda aislado de la API — los mismos registros, validación y automatizaciones alimentan la UI y cada llamada a /v1.
La web, la app nativa de iOS/Android y tus integraciones hablan todas con el mismo backend — construye una vez y se comporta igual en todas partes.
Cada respuesta está fundamentada en tus datos reales y aislados por tenant. Sin reescritura oculta de registros por IA — la automatización y el copiloto GENE solo actúan sobre lo que permites.
OAuth 2.0 client-credentials más una concesión de intercambio de usuario fueron diseñados para apps de socios que incrustan GENECRM de forma headless detrás de su propia UI.
Una key que generas tú mismo, con el alcance que necesites
Genera una key desde Configuración → Desarrolladores — sin ticket de soporte, sin esperas. Dale alcance de solo lectura para una integración de reportes o de lectura+escritura para algo que crea y actualiza registros, y revócala al instante si se filtra.
- Autoservicio — crea, rota y revoca keys desde la configuración dentro de la app
- Con alcance de lectura o lectura+escritura; cada key resuelve a un tenant y una identidad de servicio
- Se envía como un header X-API-Key en cada solicitud — sin sesión, sin cookies
- El uso de cada key se desglosa por separado en GET /v1/usage
Client-credentials para apps que actúan en su propio nombre
Registra un cliente OAuth, intercambia su client_id/secret por un access token de vida corta y rotativo, y luego úsalo como un Bearer token normal en cualquier endpoint /v1 — la alternativa amigable para empresas frente a una API key estática viviendo en el código de un socio.
- POST /oauth/token — grant_type=client_credentials + client_id + client_secret
- Devuelve un JWT de vida corta y con alcance: { access_token, token_type: "Bearer", expires_in }
- Úsalo como Authorization: Bearer <token> en cualquier recurso /v1
- Para apps incrustadas/de socios, intercámbialo de nuevo por la identidad de un usuario real — ver abajo
Una sola forma, un solo límite, cada recurso bajo /v1.
Cada recurso a continuación comparte la misma forma de petición y respuesta, la misma paginación (?limit=&offset=), y el mismo límite de seguridad a nivel de fila — list y create devuelven solo las filas de tu tenant, punto. La cobertura de escritura varía según el recurso; la especificación OpenAPI es la lista exacta.
Eventos firmados, un registro de entregas y nada perdido
Suscribe una URL a los eventos que te importan — crm.contact.create, crm.lead.create, crm.opportunity.update y más. Cada entrega está firmada con HMAC para que puedas confiar en el payload, cada intento queda registrado y las fallas caen en una dead-letter queue que puedes reenviar.
- POST /v1/webhooks — { url, events: [...] } devuelve un secreto de firma, mostrado una sola vez
- Cada entrega lleva X-GeneCRM-Signature: sha256=<hmac> sobre el body en crudo
- Historial completo de entregas en GET /v1/webhooks/deliveries
- Las entregas fallidas reintentan hasta 5×, luego quedan en GET /v1/webhooks/events/failed para su reenvío
Medido por plan, visible en tiempo real.
Los límites de tasa por minuto se escalan por plan y se aplican en el edge; una cuota mensual de llamadas separada se mide por tenant. Ambos son consultables, así que nada sobre tu uso es una sorpresa.
Premium ≈ 120 req/min, Pro ≈ 600 req/min — si lo superas obtienes 429 con un header Retry-After, no una caída silenciosa.
Una cuota mensual de llamadas separada se mide por tenant. Una vez gastada, las llamadas siguientes devuelven HTTP 402 Payment Required hasta que el período se reinicie o mejores tu plan.
El uso del período actual frente al límite de tu plan, desglosado por API key — construye tu propio panel o simplemente revisa antes de lanzar.
Los límites de tu plan y qué funciones restringidas están activas — incluyendo api_access en sí, que está disponible desde Pro.
Una especificación desde la que puedes generar un cliente, en cualquier lenguaje
La API completa está descrita por una especificación OpenAPI/Swagger generada a partir del mismo esquema que sirve la API — no puede desincronizarse. Combínala con una guía de primeros pasos y gestión de keys de autoservicio, y estarás haciendo tu primera llamada en minutos.
- Especificación OpenAPI legible por máquina en /openapi.json — genera un cliente para cualquier lenguaje
- Clientes de referencia en Python y TypeScript, más un helper de verificación de webhooks
- Una guía de primeros pasos te lleva por tu primera key, primera llamada y primer webhook
- Gestiona keys y clientes OAuth tú mismo: Configuración → Desarrolladores, sin ticket de soporte
Ejecuta GENECRM dentro de tu propio producto.
Las integraciones de socios y de plataforma no tienen que compartir una única cuenta de servicio. Intercambia el token de tu app OAuth por la identidad de un usuario real, y cada acción se atribuye a esa persona — con la garantía completa de aislamiento por tenant intacta.
El handshake de incrustación en tres pasos
- 1. Token a nivel de app. Tu backend intercambia su client_id/secret de OAuth por un Bearer token con alcance de app vía
POST /oauth/token. - 2. Intercambio de usuario. Tu backend llama a
POST /v1/auth/exchangecon el token de app más el ID externo y el correo electrónico del usuario que inició sesión — GENECRM encuentra o crea a ese usuario y devuelve su propio access token. - 3. Proxy, por usuario. Tu UI llama a
/v1/**a través de tu propio proxy con el token de ese usuario — cada escritura se atribuye a la persona real, con alcance a su firma mediante la seguridad a nivel de fila.
Una API versionada, dos formas de entrar — API keys u OAuth 2.0 — cada recurso bajo una sola ruta, webhooks firmados en los que puedes confiar, y un uso que puedes ver antes de chocar con un muro.
Preguntas que los desarrolladores realmente hacen.
Las API keys son el camino rápido para tus propios scripts y herramientas internas: genera una en Configuración → Desarrolladores y envíala como X-API-Key. OAuth 2.0 client-credentials es para una app de socio o integración que actúa en su propio nombre — un Bearer token rotativo y de vida corta en lugar de un secreto estático en cada solicitud.
Los límites de tasa por minuto se escalan por plan (Premium ≈ 120 req/min, Pro ≈ 600 req/min) y devuelven 429 con un header Retry-After. La cuota mensual de llamadas a la API, que es separada, se mide de forma independiente — una vez agotada, las llamadas siguientes devuelven 402 Payment Required hasta que el período se reinicie o mejores tu plan.
Cada entrega está firmada: el header X-GeneCRM-Signature lleva sha256=<hmac>, un HMAC-SHA256 del body en crudo de la solicitud usando el secreto de tu endpoint (mostrado una sola vez al crearlo). Recalcúlalo y compáralo con una verificación de tiempo constante antes de confiar en el payload — nunca confíes en una entrega sin firmar o con firma no coincidente.
Las entregas reintentan automáticamente hasta 5 veces con backoff. Si aun así fallan, el evento cae en la dead-letter queue (GET /v1/webhooks/events/failed) y puedes reenviarlo bajo demanda una vez que tu endpoint vuelva — sin eventos perdidos.
Cada espacio de trabajo que creas ya es un tenant aislado, así que un segundo espacio de trabajo es tu entorno de desarrollo: construye y prueba contra él con sus propias keys, y luego apunta tu integración a tu espacio de trabajo de producción cuando estés listo. No hay una separación aparte de keys de prueba y de producción que tengas que gestionar.
Cada recurso vive bajo /v1. Agregamos campos y endpoints de forma retrocompatible dentro de una versión; un cambio incompatible obtiene una nueva versión en lugar de cambiar /v1 silenciosamente bajo tus pies.
La app móvil usa su propia concesión de contraseña: POST /v1/auth/token con email + password devuelve un access token de vida corta más un refresh token rotativo, que se renueva sin pedirle al usuario que inicie sesión de nuevo. Es un flujo separado de las API keys y las apps OAuth, con alcance al usuario que inició sesión.
GET /v1/usage devuelve el uso de tu período actual frente al límite de tu plan, desglosado por API key, y GET /v1/entitlements devuelve los límites de tu plan y qué funciones restringidas — como api_access en sí — están habilitadas.