OAuth2 client credentials
APIs que no dan un token fijo sino un Client ID y un Client secret para pedir tokens que vencen. Qué completar, qué hace Nxar por detrás y cómo saber que funcionó.
Cuándo. La documentación del servicio habla de OAuth2, client credentials o machine-to-machine, y en su panel te da un Client ID, un Client secret y la dirección de un token endpoint. Pasa con muchos sistemas de gestión en la nube y APIs corporativas. El token que entregan dura poco (una hora, típicamente) y hay que pedir otro cuando vence.
Qué hace Nxar. Se encarga del ida y vuelta por vos. Antes de llamar a la API:
- Si ya tiene un token vigente para esta integración, lo usa.
- Si no tiene, o está por vencer (le queda menos de un minuto), hace un POST a la Token URL con
grant_type=client_credentials, el Client ID, el Client secret y el Scope, y guarda el token que recibe. - Llama a la API con
Authorization: Bearery ese token.
Si el servicio entrega también un refresh token, Nxar lo usa para renovar; si eso falla, vuelve a pedir uno con las credenciales.
No hay un servicio público de prueba para este tipo: necesitás las credenciales de la API real. Lo que sigue usa direcciones de ejemplo; reemplazalas por las de tu proveedor.
Un workspace con el escenario ya armado, que se borra solo a las 48 h. Estamos terminándolo.
Creá la integración con la URL de la API
ConfiguraciónIntegraciones y APIIntegrationsNueva Integration: Etiqueta ERP en la nube (OAuth2), Nombre erp_oauth2, Método GET, y en URL la dirección base de la API (no la del token), por ejemplo https://api.example.com/v1. Crear.
Completá las credenciales
Editar. En Autenticación, Tipo: OAuth2 (client credentials):
- Token URL: el token endpoint que figura en la documentación, por ejemplo
https://auth.example.com/oauth/token. - Client ID y Client secret: los que te dio el proveedor. El secret se guarda cifrado.
- Scope (opcional): sólo si la documentación lo pide, separado por espacios (
read write).
Guardar, volvé a la lista y reabrí la integración.
Probala contra un endpoint real
En Test, en Path (opcional) poné un endpoint de lectura simple de la API (la documentación suele tener uno como /me o /status) y Ejecutar Test.
Cómo saber si funcionó
- 200 con datos: el token se obtuvo y la API lo aceptó. Las llamadas siguientes reusan ese token hasta que venza.
- 401 o 403 de la API: el token se obtuvo, pero no alcanza. Suele ser el Scope, o que la aplicación no tiene permisos en el proveedor.
- Un error en rojo en vez de un resultado: falló el pedido del token, antes de llegar a la API. Mirá la Token URL, el Client ID y el Client secret. Ese pedido no aparece en Llamadas recientes, porque la API nunca se llamó.
El detalle completo del error lo ves cuando la llamada sale desde una automation: en los Logs de ejecución, la corrida fallida dice OAuth2 token request failed (HTTP 401): … seguido de lo que contestó el proveedor.
Nxar manda el Client ID y el Client secret en el cuerpo del pedido del token. Si tu proveedor sólo los acepta en un header Authorization: Basic, este tipo no le sirve tal cual.
Si cambiás el Client secret, el token que Nxar ya tenía se sigue usando hasta que vence. Para comprobar las credenciales nuevas, esperá a que venza el token (lo que dure según el proveedor) antes de sacar conclusiones.
Cómo saber que te salió
Ejecutar Test contra un endpoint de lectura de tu API devuelve 200 con datos. Si ves un error en rojo, el problema está en el pedido del token, no en la API.
¿Te funcionó?