Inicio › Desarrolladores › Documentación › API Key y ARI
API Key y ARI
Las dos vías de petición-respuesta desde tu backend: la API Key para consultar (historial de llamadas, presencia, transcripciones — solo lectura) y la ARI para originar llamadas (click-to-call). En ambas, la credencial vive en tu servidor y nunca sale al navegador.
Panorama
Conexia Infinity ofrece cinco vías de integración; esta referencia cubre las dos de backend → plataforma. Se complementan con las «en vivo» (Real-time API y Conector MCP) y con el Webhook, documentadas aparte.
| Vía | Qué resuelve | Modelo |
|---|---|---|
| API Key | Consultar histórico (CDR), presencia del equipo, grabaciones y transcripciones | Consulta (solo lectura) |
| ARI | Originar llamadas (click-to-call), colgar canal | Comando (dispara una acción) |
Convención de esta guía — Los valores entre <ángulos> son marcadores que sustituyes por los de tu instalación (<TU_SERVIDOR>, <API_KEY>, <TENANT>, <ARI_URL>, <EXT>…). Las credenciales y endpoints de tu tenant te los facilita tu contacto de Conexia; no se publican aquí.
Sobre el prefijo de las acciones — El nombre de cada acción va precedido de un prefijo del motor de la plataforma, que aquí aparece como <PREFIJO>. Te lo facilita tu contacto de Conexia junto con las credenciales, igual que <TU_SERVIDOR> o <API_KEY>. Sustitúyelo por el valor real de tu instalación para que la petición funcione.
Ambas viven en el backend — Ni la API Key ni las credenciales ARI deben salir nunca al navegador. El navegador pulsa botones y muestra datos; es tu backend quien guarda las credenciales y habla con la plataforma.
Parte A · API Key — consultar: qué es y cómo autentica
La API Key es una vía HTTP de solo lectura: preguntas, la plataforma responde. Es la fuente correcta para datos cerrados (llamadas de días pasados, configuración, presencia), no para tiempo real —eso es la Real-time API—.
- Autenticación: parámetro
apikeyen la URL. - Transporte: HTTPS · GET.
- Dónde: backend, servidor a servidor.
- Buenas prácticas: cachea lo que cambia poco (CDR de días cerrados, configuración); no sondees en bucle apretado.
Tu código de tenant — Muchas peticiones usan tu server (código de tenant). Se obtiene una vez con <PREFIJO>.tenant.list y se reutiliza en las llamadas siguientes.
Historial de llamadas (CDR)
Para poblar la pestaña de actividad del contacto, cuadros de mando y reporting.
Flujo típico de sincronización
<PREFIJO>.tenant.listuna vez para conocer tuserver(código de tenant).<PREFIJO>.cdr.downloadperiódicamente, por rango de fechas y paginado, para traer las llamadas nuevas. Cruza los campos de origen/destino con tus contactos.- Por cada llamada con grabación disponible, pide
<PREFIJO>.transcription.getcon su identificador único y adjunta el texto a la actividad. - Guarda la última fecha sincronizada para pedir solo lo nuevo la próxima vez.
GET https://<TU_SERVIDOR>/index.php?action=<PREFIJO>.cdr.download
&apikey=<API_KEY>&apiformat=json&server=<TENANT>
&start=<Mmm-DD-YYYY>&end=<Mmm-DD-YYYY>&page=0
// fecha en formato Mmm-DD-YYYY (mes en inglés). Sube page mientras haya más resultados.
Cómo leer el CDR — La respuesta trae las columnas y las filas por separado: empareja por posición. La dirección se deduce de origen/destino (extensión→externo = saliente; al revés = entrante; ambas extensiones = interna). El identificador único de la llamada es la clave para cruzar con su grabación y transcripción.
Grabaciones y transcripción
Cuando una llamada tiene grabación disponible, puedes pedir su transcripción con <PREFIJO>.transcription.get usando el identificador único de la llamada, y adjuntar el texto a la actividad del contacto en el CRM.
Complementa, no dupliques — Para reporting y cruce masivo con el CRM, usa el CDR de la API Key. La Real-time API ofrece además un «historial reciente» pensado para la interfaz del propio agente; no mezcles ambos como misma fuente de verdad.
Presencia del equipo
<PREFIJO>.monitor.list devuelve el estado de todas las extensiones del tenant: ideal para un panel de supervisión del equipo completo. Refresca cada pocos segundos; no sondees en bucle apretado.
{ "0": { "ext":"<EXT>", "name":"<NOMBRE>", "status":"online", "on_call":"0", "dnd":"0" },
"1": { "ext":"<EXT>", "name":"<NOMBRE>", "status":"online", "on_call":"1", "dnd":"0" } }
// derivación: offline si status≠online; si no → en llamada (on_call=1), no molestar (dnd=1)
Todo el equipo vs. en vivo — ¿Necesitas ver a todo el equipo desde un panel? → API Key (monitor.list). ¿Reflejar en vivo el estado en la interfaz del propio agente? → los hints de la Real-time API.
Parte B · ARI — originar (click-to-call): qué es y cómo autentica
La ARI es la vía para originar llamadas desde tu backend: haces sonar la extensión del agente y, al descolgar, la centralita marca al destino y los une. Una sola petición REST resuelve el click-to-call.
- Autenticación: Basic Auth (
usuario:contraseña). - Transporte: HTTPS · REST.
- Restricción por IP: la ARI solo acepta peticiones desde las IPs autorizadas (la IP pública de tu servidor). Es una capa de seguridad, no un obstáculo.
- Dónde: backend. La credencial nunca sale al cliente.
Click-to-call desde la ficha
El botón «Llamar» sobre un teléfono del contacto.
- El agente pulsa «Llamar» en la ficha. El navegador solo avisa a tu backend (extensión del agente + número del contacto). La credencial ARI no sale al cliente.
- Tu backend hace
POST /channelsa la ARI con Basic Auth. - Suena el teléfono del agente; al descolgar, la centralita marca al destino y conecta.
- En paralelo, tu puente Real-time recibe
event_call_started(state:2, Ring Out): úsalo para reflejar el estado en la interfaz.
POST https://<ARI_URL>/channels
Authorization: Basic base64(<ARI_USER>:<ARI_PASS>)
Content-Type: application/x-www-form-urlencoded
endpoint=Local/<EXT>@<TENANT> // EXT = extensión del agente; TENANT = contexto del tenant
&extension=<DESTINO> // número del contacto (destino)
&context=<TENANT>&priority=1&timeout=40&app=<APP>
Normaliza antes de enviar — La extensión, solo dígitos; el destino, solo caracteres marcables (0-9 * # +). Rechaza en tu lado las peticiones sin destino válido. El CallerID de salida es el DDI propio de la extensión, según la centralita — no se envía uno personalizado en la petición.
¿Y si necesito control fino del dispositivo?
Con la ARI, Local/<EXT> hace sonar los dispositivos de esa extensión según su configuración. Si necesitas elegir «solo softphone» o «solo móvil», eso se hace mejor con el comando call de la Real-time API y su parámetro device.
Diagnóstico: 403 al originar
Lo más habitual — Un 403 al originar casi siempre es la restricción por IP: la ARI solo acepta peticiones desde las IPs que autorizaste con Conexia. Verifica la lista blanca antes de sospechar de las credenciales.
- ¿Cambió la IP pública de tu servidor? Si tu backend salió por otra IP (proxy, nuevo despliegue), la lista blanca ya no coincide.
- ¿Credenciales correctas pero mismo 403? Es señal casi segura de IP, no de auth.
Cómo empezar
- Solicita credenciales. Pide a tu contacto de Conexia tu
<API_KEY>, tu código de tenant y las credenciales ARI; para la ARI, indica la IP pública de tu servidor para la lista blanca. - Empieza por consultar. Con la API Key, sincroniza el CDR y muéstralo en la actividad del contacto. Es de solo lectura: bajo riesgo.
- Añade el click-to-call con la ARI (
POST /channels) desde el backend. - Combina con las vías en vivo (Real-time API) para el Call Popup y el control de la llamada.
¿Buscas las otras vías? Consulta la referencia de Real-time API y Conector MCP y la de Webhook en el índice de integraciones.
Conexia Telecom · Referencia — API Key y ARI — Documento para desarrolladores. Los valores entre <ángulos> son marcadores; los endpoints y credenciales de tu tenant los facilita tu contacto de Conexia. La disponibilidad de funciones depende de la versión y la licencia de la instalación.