Autenticación

La API de Rently usa OAuth2 con tokens Bearer. El flujo es simple: pedís un token con tus credenciales, lo guardás y lo enviás en el header Authorization de cada request. Esta guía cubre cómo obtener el token, cómo usarlo, su expiración y la relación entre el token y tu tenant.

El modelo en una frase

1. Hacés POST /auth/token con tus credenciales y recibís un access_token.
2. Enviás ese token en el header Authorization: Bearer {token} en cada llamada a /api/....
3. El token queda ligado a tu tenant (tu host) y vence al día (expires_in ≈ 86399 segundos).

Credenciales

Tu client_id es tu usuario de Rently y tu client_secret es tu clave. Si todavía no tenés un usuario habilitado para la API, contactá a tu administrador de Rently.

Obtener el token

El endpoint de token vive en el host de tu tenant y se llama con grant_type=client_credentials. El cuerpo se envía como application/x-www-form-urlencoded.

curl -X POST https://{tenant}.rently.com.ar/auth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id={username}" \
  -d "client_secret={password}"

Probalo en vivo

Podés probar este endpoint de forma interactiva —completá client_id, client_secret y el host de tu tenant, y enviá la request— en el reference: Obtener un token de acceso.

El token endpoint vive en el host de tu tenant

https://{tenant}.rently.com.ar se usa de ejemplo: reemplazá {tenant} por tu tenant. En producción tenés que apuntar tanto el endpoint de token como las llamadas de negocio al host de tu tenant. El host identifica al tenant: el token que emite queda ligado a ese tenant. Usar el token contra un host de otro tenant falla la validación (ver Rol del tenant).

Parámetros del cuerpo

Campo	Valor	Descripción
grant_type	client_credentials	Valor fijo. Es el flujo que usan los clientes de la API.
client_id	tu usuario	Usuario de Rently habilitado para la API.
client_secret	tu clave	Clave del usuario.

Respuesta

Si las credenciales son válidas, recibís un JSON con el token:

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiAi...",
  "token_type": "bearer",
  "expires_in": 86399
}

Campo	Tipo	Descripción
access_token	string	El token a enviar en cada request.
token_type	string	Esquema de autorización. Siempre bearer.
expires_in	number	Segundos hasta la expiración (≈ 1 día).

tip

Guardá el access_token y reutilizalo en todas tus llamadas hasta que expire. No pidas un token nuevo en cada request: el token es válido durante todo el día.

Usar el Bearer token

En cada llamada a la API enviás el token en el header Authorization, con el esquema Bearer:

Authorization: Bearer {access_token}

Ejemplo de un request autenticado contra un endpoint real de la API. GET /api/branchoffices lista las sucursales activas:

curl -X GET "https://{tenant}.rently.com.ar/api/branchoffices?language=es-AR" \
  -H "Authorization: Bearer {access_token}"

Idioma de la respuesta

El query param ?language= controla el idioma de la respuesta (por ejemplo ?language=es-AR). Si lo omitís, se usa el idioma por defecto de tu tenant. Aceptá tanto la cultura completa (es-AR) como el código de dos letras (es).

Todos los endpoints de negocio (/api/...) requieren este header. Podés ver el detalle de cada operación, sus parámetros y sus respuestas en la API Reference →.

Expiración y renovación

El token vence aproximadamente un día después de emitirse (expires_in ≈ 86399 segundos). No existe un mecanismo de refresh token: cuando el token expira, simplemente pedís uno nuevo repitiendo el POST /auth/token con tus credenciales.

Si enviás un token expirado, ausente o inválido, la API responde 401 Unauthorized con un header WWW-Authenticate que apunta al endpoint de token de tu tenant:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer authorization_uri=https://{tenant-host}/auth/token, resource_id=https://{tenant-host}/api

Estrategia recomendada

Guardá la fecha/hora en la que pediste el token y renovalo de forma proactiva antes de que se cumpla expires_in. Como alternativa reactiva, ante un 401 volvé a pedir el token y reintentá el request.

Rol del tenant

El tenant se resuelve a partir del host de la URL. Cuando obtenés un token, el tenant correspondiente a ese host queda embebido en el token como un claim.

En cada llamada de negocio, la API valida dos cosas:

1. Que el token sea válido y no haya expirado.
2. Que el tenant del token coincida con el tenant del host de la request.

Un token = un tenant

Un token emitido para un tenant no sirve para otro. Si reutilizás un token contra el host de un tenant distinto, la validación falla con 401. Pedí siempre el token en el mismo host donde vas a hacer las llamadas de negocio.

Además, emitir el token y autorizar cada endpoint son capas separadas: el usuario debe estar habilitado para usar la API, y luego cada operación aplica sus propios permisos. Si tu usuario no tiene permiso sobre un endpoint, la request puede ser rechazada aunque el token sea válido.

Resumen

• Token: POST /auth/token con grant_type=client_credentials, client_id (usuario) y client_secret (clave), como application/x-www-form-urlencoded, sobre el host de tu tenant.
• Respuesta: access_token, token_type: "bearer", expires_in (≈ 1 día).
• Uso: header Authorization: Bearer {access_token} en cada llamada a /api/....
• Expiración: ≈ 1 día, sin refresh token; pedí un token nuevo cuando expire.
• Tenant: el token queda ligado al host/tenant donde lo pediste; no lo reutilices contra otro tenant.

Con el token en mano, seguí explorando los endpoints en la API Reference →.