zendesk-oauth-app-creation

eesel Team
Written by

eesel Team

Last edited 2 marzo 2026

{
  "title": "Cómo crear una aplicación OAuth de Zendesk: Una guía completa para 2026",
  "slug": "zendesk-oauth-app-creation",
  "locale": "es",
  "date": "2026-03-02",
  "updated": "2026-03-02",
  "template": "default",
  "excerpt": "Una guía completa para crear aplicaciones OAuth en Zendesk, que cubre todo, desde el registro del cliente hasta la implementación del flujo de autorización con ejemplos de código prácticos.",
  "categories": [
    "Zendesk",
    "Guides"
  ],
  "tags": [
    "Zendesk",
    "OAuth",
    "API",
    "Integration",
    "Developer Guide"
  ],
  "readTime": 9,
  "author": 16,
  "reviewer": 14,
  "seo": {
    "title": "Cómo crear una aplicación OAuth de Zendesk: Una guía completa para 2026",
    "description": "Una guía completa para crear aplicaciones OAuth en Zendesk, que cubre todo, desde el registro del cliente hasta la implementación del flujo de autorización con ejemplos de código prácticos.",
    "image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-040e5b19-d249-4b97-a37d-7c0bf1759a97"
  },
  "coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-040e5b19-d249-4b97-a37d-7c0bf1759a97",
  "coverImageAlt": "Imagen del banner para Cómo crear una aplicación OAuth de Zendesk: Una guía completa para 2026",
  "coverImageWidth": 1920,
  "coverImageHeight": 1080,
  "faqs": {
    "heading": "Preguntas Frecuentes",
    "type": "blog",
    "answerType": "html",
    "faqs": [
      {
        "question": "¿Necesito un plan de pago de Zendesk para crear una aplicación OAuth?",
        "answer": "Sí, la creación de clientes OAuth requiere el plan Zendesk Suite Growth o superior, o el plan Support Professional o superior. Los planes Team no incluyen la gestión de clientes OAuth."
      },
      {
        "question": "¿Puedo usar localhost para probar mi aplicación OAuth de Zendesk?",
        "answer": "Sí, Zendesk permite http://localhost y http://127.0.0.1 como URL de redireccionamiento durante el desarrollo. Asegúrese de registrar la URL exacta, incluidos los números de puerto."
      },
      {
        "question": "¿Cuál es la diferencia entre los tokens de API y OAuth para las integraciones de Zendesk?",
        "answer": "Los tokens de API están vinculados a una cuenta de usuario específica y tienen permisos completos. OAuth permite a los usuarios otorgar permisos específicos y limitados a las aplicaciones sin compartir su contraseña. OAuth es preferible para aplicaciones de producción e integraciones multiusuario."
      },
      {
        "question": "¿Cuánto duran los tokens de acceso OAuth de Zendesk?",
        "answer": "Puede configurar la caducidad del token entre 300 segundos (5 minutos) y 172.800 segundos (2 días) al solicitar tokens. Los tokens de actualización duran entre 7 y 90 días, dependiendo de su configuración."
      },
      {
        "question": "¿Puedo solicitar un cliente OAuth global para mi aplicación de Zendesk?",
        "answer": "Sí, si su aplicación necesita integrarse con varias cuentas de Zendesk, puede solicitar un cliente OAuth global. Esto proporciona una experiencia de autenticación más limpia para los usuarios en diferentes instancias de Zendesk. Póngase en contacto con el soporte para desarrolladores de Zendesk para solicitarlo."
      }
    ],
    "supportLink": null
  }
}
---

Si está creando una integración con Zendesk, eventualmente necesitará autenticar sus solicitudes de API. Si bien los tokens de API funcionan para scripts simples, OAuth es el estándar para aplicaciones de producción que acceden a los datos de Zendesk en nombre de los usuarios. Permite a los usuarios otorgar permisos específicos sin compartir sus contraseñas, y le brinda un control preciso sobre a qué puede acceder su aplicación.

Pero aquí está la cuestión: configurar OAuth puede parecer complicado si nunca lo ha hecho antes. Hay redireccionamientos, códigos de autorización, alcances y secretos para administrar. Esta guía lo guía a través de todo el proceso paso a paso, desde el registro de su aplicación hasta la realización de su primera llamada API autenticada.

Si está buscando un enfoque más simple, [eesel AI](https://www.eesel.ai) maneja la autenticación de Zendesk automáticamente. Conecta su cuenta una vez y nosotros administramos el flujo de OAuth en segundo plano. Pero si necesita crear una integración personalizada, siga leyendo.

![Panel de control de eesel AI con fuentes de conocimiento conectadas](https://website-cms.eesel.ai/wp-content/uploads/2025/09/05-eesel-AI-integrations-as-an-alternative-to-the-Zendesk-Guide-pricing-model.png)

## Lo que necesitará

Antes de comenzar, asegúrese de tener:

- Una cuenta de [Zendesk](https://www.zendesk.com) en el plan Suite Growth o superior, o en el plan Support Professional o superior
- Acceso de administrador a su instancia de Zendesk (o alguien que pueda otorgarlo)
- Una comprensión básica de los conceptos de OAuth 2.0 (códigos de autorización, tokens de acceso, redireccionamientos)
- Un entorno de desarrollo donde pueda probar el flujo de OAuth

Si solo está experimentando, Zendesk ofrece [cuentas de prueba para desarrollo](https://developer.zendesk.com/documentation/api-basics/getting-started/getting-a-trial-or-sponsored-account-for-development/). También puede revisar la [documentación oficial de OAuth de Zendesk](https://support.zendesk.com/hc/en-us/articles/4408845965210) para obtener los detalles más recientes sobre los flujos de autenticación y los endpoints (puntos de conexión).

## Paso 1: Registrar su cliente OAuth en Zendesk

El primer paso es informarle a Zendesk sobre su aplicación. Esto crea un cliente OAuth que los usuarios autorizan cuando conectan su aplicación.

![Página de inicio de Zendesk para acceder al Centro de administración](https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/screenshots/zendesk-landing-page.png)

**Navegue a la sección Clientes OAuth:**

1. Inicie sesión en Zendesk y vaya al Centro de administración (haga clic en el icono de engranaje en la barra lateral)
2. Seleccione **Aplicaciones e integraciones** en la barra lateral izquierda
3. Haga clic en **API** → **Clientes OAuth**
4. Haga clic en **Agregar cliente OAuth** en el lado derecho

**Complete los detalles del cliente:**

- **Nombre:** Un nombre para mostrar de su aplicación. Los usuarios ven esto al autorizar su aplicación.
- **Descripción:** Opcional, pero ayuda a los usuarios a comprender lo que hace su aplicación
- **Empresa:** El nombre de su empresa
- **Logotipo:** Opcional. Cargue una imagen cuadrada (JPG, GIF o PNG) que represente su aplicación
- **Tipo de cliente:** Elija entre Público o Confidencial
  - **Confidencial:** Para aplicaciones del lado del servidor donde puede almacenar de forma segura el secreto del cliente
  - **Público:** Para aplicaciones móviles o aplicaciones de JavaScript donde el secreto podría estar expuesto. Estos deben usar PKCE.
- **URL de redireccionamiento:** Las URL a las que Zendesk enviará a los usuarios después de que autoricen su aplicación. Debe ser HTTPS (excepto para localhost durante el desarrollo). Agregue varias URL en líneas separadas si es necesario.

**Guarde sus credenciales:**

Después de hacer clic en **Guardar**, Zendesk genera un **ID de cliente** (llamado "Identificador") y un **Secreto de cliente**. Copie ambos inmediatamente, el secreto solo se muestra una vez. Si lo pierde, deberá generar uno nuevo.

## Paso 2: Elija el flujo OAuth correcto

Zendesk admite dos tipos principales de concesión de OAuth 2.0. Elija el que coincida con su caso de uso.

El **flujo de código de autorización** es para aplicaciones orientadas al usuario. Cuando un usuario quiere conectar su aplicación a su cuenta de Zendesk, lo redirige a la página de autorización de Zendesk. Inician sesión, aprueban los permisos y Zendesk los envía de vuelta a su aplicación con un código de autorización. Su servidor intercambia este código por un token de acceso.

Este flujo admite tokens de actualización, por lo que puede obtener nuevos tokens de acceso sin pedirle al usuario que vuelva a autorizar. Los tokens de acceso caducan (puede establecer esto entre 5 minutos y 2 días), pero los tokens de actualización duran más (de 7 a 90 días).

El **flujo de credenciales de cliente** es para la autenticación de máquina a máquina. No hay ningún usuario involucrado. Su aplicación utiliza su ID de cliente y su secreto para obtener un token de acceso directamente. Esto funciona bien para los servicios de backend que necesitan acceder a los datos de Zendesk de forma programada.

**PKCE (Proof Key for Code Exchange)** agrega seguridad para los clientes públicos. Si está creando una aplicación móvil o una aplicación de una sola página donde no puede almacenar de forma segura un secreto de cliente, use PKCE con el flujo de código de autorización. Evita los ataques de interceptación del código de autorización.

![Diagrama de flujo de autorización de OAuth que muestra el intercambio seguro de tokens](https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/b34968f5-6c80-4d15-be0d-4cfd199d39ae)

## Paso 3: Configure los alcances de OAuth

Los alcances controlan a qué puede acceder su aplicación en Zendesk. Sea específico, solicitar solo los permisos que realmente necesita sigue el principio del privilegio mínimo y hace que sea más probable que los usuarios confíen en su aplicación.

Zendesk ofrece tres tipos principales de alcance:

- **read (lectura):** Acceso a los endpoints (puntos de conexión) GET. Incluye el permiso para cargar recursos relacionados.
- **write (escritura):** Acceso a los endpoints (puntos de conexión) POST, PUT y DELETE para crear, actualizar y eliminar recursos.
- **impersonate (suplantar):** Permite a los administradores realizar solicitudes de API en nombre de los usuarios finales.

También puede solicitar alcances específicos de recursos para un control más preciso:

- `tickets:read` o `tickets:write`
- `users:read` o `users:write`
- `organizations:read` o `organizations:write`
- `macros:read` o `macros:write`
- `triggers:read` o `triggers:write`

Por ejemplo, si su aplicación solo necesita leer tickets y actualizar perfiles de usuario, solicite `tickets:read users:write` en lugar de acceso general `read write`.

**Importante:** Los permisos reales de un usuario en Zendesk siguen siendo aplicables. Incluso si su alcance de OAuth permite escribir tickets, un usuario con acceso de solo lectura no puede crear tickets a través de su aplicación.

## Paso 4: Implemente el flujo de autorización

Aquí se explica cómo implementar el flujo de código de autorización, el enfoque más común para las aplicaciones web.

**Envíe a los usuarios al endpoint (punto de conexión) de autorización:**

Redirija a los usuarios a esta URL con los parámetros requeridos:

https://{subdominio}.zendesk.com/oauth/authorizations/new


Incluya estos parámetros de consulta:

- `response_type=code` (obligatorio)
- `client_id={su_id_de_cliente}` (obligatorio)
- `redirect_uri={su_url_de_redireccionamiento}` (obligatorio, debe coincidir con lo que registró)
- `scope={alcances_solicitados}` (obligatorio, separados por espacios)
- `state={cadena_aleatoria}` (recomendado, previene ataques CSRF)

Ejemplo de URL:

https://suempresa.zendesk.com/oauth/authorizations/new?response_type=code&client_id=su_id_de_cliente&redirect_uri=https://suaplicacion.com/callback&scope=read%20write&state=abc123


**Maneje el redireccionamiento:**

Después de que el usuario aprueba o deniega el acceso, Zendesk lo redirige a su `redirect_uri` con:

- Un código de autorización: `?code=7xqwtlf3rrdj8uyeb1yf&state=abc123`
- Un error: `?error=access_denied&error_description=User+denied+access`

Verifique que el parámetro `state` coincida con lo que envió, luego extraiga el código. Los códigos de autorización caducan después de 120 segundos, así que intercámbielos de inmediato.

**Intercambie el código por tokens:**

Realice una solicitud POST al endpoint (punto de conexión) de token de Zendesk:

```python
import requests

response = requests.post(
    f'https://{subdominio}.zendesk.com/oauth/tokens',
    data={
        'grant_type': 'authorization_code',
        'code': authorization_code,
        'client_id': client_id,
        'client_secret': client_secret,
        'redirect_uri': redirect_uri,
        'scope': 'read',
        'expires_in': 172800,  # 2 días
        'refresh_token_expires_in': 7776000  # 90 días
    }
)

tokens = response.json()
access_token = tokens['access_token']
refresh_token = tokens['refresh_token']

Almacene ambos tokens de forma segura. El token de acceso es lo que usará para las llamadas API. El token de actualización le permite obtener nuevos tokens de acceso cuando el actual caduca.

Paso 5: Use tokens de acceso en las solicitudes API

Con un token de acceso, ahora puede realizar solicitudes autenticadas a la API de Zendesk.

Incluya el token en el encabezado de autorización:

Authorization: Bearer {token_de_acceso}

Ejemplo de solicitud:

import requests

headers = {'Authorization': f'Bearer {access_token}'}
response = requests.get(
    f'https://{subdominio}.zendesk.com/api/v2/tickets.json',
    headers=headers
)

Maneje la caducidad del token:

Cuando un token de acceso caduca, las solicitudes API devuelven un estado 401 con este error:

{
  "error": "invalid_token",
  "error_description": "The access token provided is expired, revoked, malformed or invalid for other reasons."
}

Use su token de actualización para obtener un nuevo token de acceso:

response = requests.post(
    f'https://{subdominio}.zendesk.com/oauth/tokens',
    data={
        'grant_type': 'refresh_token',
        'refresh_token': refresh_token,
        'client_id': client_id,
        'client_secret': client_secret,
        'scope': 'read'
    }
)

new_tokens = response.json()

Si el token de actualización también ha caducado, deberá enviar al usuario a través del flujo de autorización nuevamente.

Problemas comunes y solución de problemas

Errores de "URI de redireccionamiento no válido": La URL de redireccionamiento en su solicitud de autorización debe coincidir exactamente con una de las URL registradas en su cliente OAuth. Verifique las barras diagonales finales, http vs https y las diferencias de subdominio.

Permiso de alcance denegado: Recuerde que los alcances de OAuth están limitados por los permisos reales de Zendesk del usuario. Un agente con acceso de solo lectura no puede escribir tickets incluso si su alcance de OAuth lo permite.

El secreto del cliente solo se muestra parcialmente: Zendesk solo muestra el secreto completo una vez, inmediatamente después de la creación. Si no lo copió, deberá generar uno nuevo en la configuración del cliente OAuth.

Pruebas con localhost: Zendesk permite http://localhost y http://127.0.0.1 como URL de redireccionamiento para el desarrollo. Asegúrese de registrar la URL exacta, incluido el puerto (por ejemplo, http://localhost:3000/callback).

Código de autorización caducado: Los códigos solo son válidos durante 120 segundos. Si su usuario tarda demasiado en autorizar, o si hay un retraso en su intercambio de código, recibirá un error. Comience el flujo de nuevo.

Mejores prácticas de seguridad

Almacene los secretos de forma segura: Nunca codifique los secretos del cliente en su código fuente ni los comprometa con el control de versiones. Use variables de entorno o un servicio de administración de secretos. La hoja de trucos de OWASP OAuth proporciona recomendaciones de seguridad adicionales para las implementaciones de OAuth.

Use HTTPS en todas partes: Todas las URL de redireccionamiento en producción deben usar HTTPS. La única excepción es localhost durante el desarrollo.

Implemente PKCE para clientes públicos: Si está creando una aplicación móvil o una aplicación basada en navegador donde el secreto podría estar expuesto, use PKCE. Genere un verificador de código, aplique un hash para crear un desafío de código y envíe el desafío con su solicitud de autorización.

Establezca una caducidad razonable del token: Los tokens de menor duración son más seguros. Para la mayoría de las aplicaciones, 24 horas es un buen equilibrio entre seguridad y conveniencia.

Rote las credenciales con regularidad: Genere periódicamente nuevos secretos de cliente y actualice sus aplicaciones. Si sospecha que un secreto ha sido comprometido, rótelo inmediatamente.

Valide el parámetro de estado: Siempre verifique que el parámetro de estado en el redireccionamiento coincida con lo que envió. Esto evita los ataques CSRF donde los sitios maliciosos engañan a los usuarios para que autoricen el acceso no deseado.

Evite la complejidad de OAuth con eesel AI

Crear una integración OAuth personalizada requiere tiempo y mantenimiento continuo. Debe manejar el flujo de autorización, la actualización del token, los casos de error y las actualizaciones de seguridad. Para muchos equipos, este no es el mejor uso del tiempo de ingeniería.

eesel AI ofrece una ruta más simple. Nuestro Agente de IA se conecta a su cuenta de Zendesk con un solo clic. Manejamos la autenticación OAuth automáticamente, para que pueda concentrarse en lo que importa: crear automatizaciones que realmente resuelvan problemas.

Panel de control sin código de eesel AI para configurar el agente de IA
Panel de control sin código de eesel AI para configurar el agente de IA

En lugar de escribir código para intercambiar códigos de autorización y actualizar tokens, puede:

  • Entrenar una IA en sus artículos del centro de ayuda y tickets anteriores
  • Configurar automatizaciones que resuelvan los tickets de extremo a extremo
  • Escalar problemas complejos a humanos con reglas en inglés sencillo
  • Ejecutar simulaciones en datos históricos antes de poner en marcha

Si está creando una integración profundamente personalizada, OAuth podría ser la opción correcta. Pero si necesita automatización de soporte impulsada por IA sin la sobrecarga de ingeniería, pruebe eesel AI.

Compartir esta entrada

eesel undefined

Article by

eesel Team