Authentification

L'API de Rently utilise OAuth2 avec des tokens Bearer. Le flux est simple : vous demandez un token avec vos identifiants, vous le conservez et vous l'envoyez dans le header Authorization de chaque requête. Ce guide couvre l'obtention du token, son utilisation, son expiration et la relation entre le token et votre tenant.

Le modèle en une phrase

1. Vous faites POST /auth/token avec vos identifiants et vous recevez un access_token.
2. Vous envoyez ce token dans le header Authorization: Bearer {token} à chaque appel à /api/....
3. Le token reste lié à votre tenant (votre host) et expire au bout d'un jour (expires_in ≈ 86399 secondes).

Identifiants

Votre client_id est votre utilisateur Rently et votre client_secret est votre clé. Si vous n'avez pas encore d'utilisateur habilité pour l'API, contactez votre administrateur Rently.

Obtenir le token

L'endpoint de token se trouve sur le host de votre tenant et s'appelle avec grant_type=client_credentials. Le corps est envoyé en 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={utilisateur}" \
  -d "client_secret={clé}"

Essayez-le en direct

Vous pouvez tester cet endpoint de manière interactive — renseignez client_id, client_secret et le host de votre tenant, puis envoyez la requête — dans la reference : Obtenir un jeton d'accès.

L'endpoint de token se trouve sur le host de votre tenant

https://{tenant}.rently.com.ar est utilisé à titre d'exemple : remplacez {tenant} par l'identifiant de votre tenant. En production, vous devez pointer aussi bien l'endpoint de token que les appels métier vers le host de votre tenant. Le host identifie le tenant : le token qu'il émet reste lié à ce tenant. Utiliser le token contre le host d'un autre tenant fait échouer la validation (voir Rôle du tenant).

Paramètres du corps

Champ	Valeur	Description
grant_type	client_credentials	Valeur fixe. C'est le flux utilisé par les clients de l'API.
client_id	votre utilisateur	Utilisateur Rently habilité pour l'API.
client_secret	votre clé	Clé de l'utilisateur.

Réponse

Si les identifiants sont valides, vous recevez un JSON contenant le token :

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

Champ	Type	Description
access_token	string	Le token à envoyer dans chaque requête.
token_type	string	Schéma d'autorisation. Toujours bearer.
expires_in	number	Secondes jusqu'à l'expiration (≈ 1 jour).

astuce

Conservez l'access_token et réutilisez-le dans tous vos appels jusqu'à son expiration. Ne demandez pas un nouveau token à chaque requête : le token est valable toute la journée.

Utiliser le token Bearer

À chaque appel à l'API, vous envoyez le token dans le header Authorization, avec le schéma Bearer :

Authorization: Bearer {access_token}

Exemple d'une requête authentifiée contre un endpoint réel de l'API. GET /api/branchoffices liste les agences actives :

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

Langue de la réponse

Le query param ?language= contrôle la langue de la réponse (par exemple ?language=es-AR). Si vous l'omettez, la langue par défaut de votre tenant est utilisée. Il accepte aussi bien la culture complète (es-AR) que le code à deux lettres (es).

Tous les endpoints métier (/api/...) requièrent ce header. Vous pouvez voir le détail de chaque opération, ses paramètres et ses réponses dans l'API Reference →.

Expiration et renouvellement

Le token expire environ un jour après son émission (expires_in ≈ 86399 secondes). Il n'existe pas de mécanisme de refresh token : lorsque le token expire, vous en demandez simplement un nouveau en répétant le POST /auth/token avec vos identifiants.

Si vous envoyez un token expiré, absent ou invalide, l'API répond 401 Unauthorized avec un header WWW-Authenticate qui pointe vers l'endpoint de token de votre tenant :

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

Stratégie recommandée

Conservez la date/heure à laquelle vous avez demandé le token et renouvelez-le de manière proactive avant que expires_in ne soit atteint. En solution réactive, face à un 401, redemandez le token et réessayez la requête.

Rôle du tenant

Le tenant est résolu à partir du host de l'URL. Lorsque vous obtenez un token, le tenant correspondant à ce host est intégré au token sous forme de claim.

À chaque appel métier, l'API valide deux choses :

1. Que le token soit valide et n'ait pas expiré.
2. Que le tenant du token corresponde au tenant du host de la requête.

Un token = un tenant

Un token émis pour un tenant ne sert pas pour un autre. Si vous réutilisez un token contre le host d'un tenant différent, la validation échoue avec 401. Demandez toujours le token sur le même host où vous allez faire les appels métier.

De plus, l'émission du token et l'autorisation de chaque endpoint sont des couches séparées : l'utilisateur doit être habilité pour utiliser l'API, puis chaque opération applique ses propres permissions. Si votre utilisateur n'a pas la permission sur un endpoint, la requête peut être rejetée même si le token est valide.

Résumé

• Token : POST /auth/token avec grant_type=client_credentials, client_id (utilisateur) et client_secret (clé), en application/x-www-form-urlencoded, sur le host de votre tenant.
• Réponse : access_token, token_type: "bearer", expires_in (≈ 1 jour).
• Utilisation : header Authorization: Bearer {access_token} à chaque appel à /api/....
• Expiration : ≈ 1 jour, sans refresh token ; demandez un nouveau token à son expiration.
• Tenant : le token reste lié au host/tenant où vous l'avez demandé ; ne le réutilisez pas contre un autre tenant.

Une fois le token en main, continuez d'explorer les endpoints dans l'API Reference →.