Autenticação

A API da Rently usa OAuth2 com tokens Bearer. O fluxo é simples: você pede um token com suas credenciais, guarda-o e o envia no header Authorization de cada request. Este guia cobre como obter o token, como usá-lo, sua expiração e a relação entre o token e o seu tenant.

O modelo em uma frase

1. Você faz POST /auth/token com suas credenciais e recebe um access_token.
2. Envia esse token no header Authorization: Bearer {token} em cada chamada a /api/....
3. O token fica vinculado ao seu tenant (seu host) e vence em um dia (expires_in ≈ 86399 segundos).

Credenciais

Seu client_id é o seu usuário da Rently e seu client_secret é a sua chave. Se você ainda não tem um usuário habilitado para a API, entre em contato com o administrador da Rently.

Obter o token

O endpoint de token vive no host do seu tenant e é chamado com grant_type=client_credentials. O corpo é enviado 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}"

Teste ao vivo

Você pode testar este endpoint de forma interativa — preencha client_id, client_secret e o host do seu tenant, e envie a request — na reference: Obter um token de acesso.

O endpoint de token vive no host do seu tenant

https://{tenant}.rently.com.ar é usado como exemplo. Em produção você precisa apontar tanto o endpoint de token quanto as chamadas de negócio para o host do seu tenant. O host identifica o tenant: o token que ele emite fica vinculado a esse tenant. Usar o token contra um host de outro tenant falha na validação (ver Papel do tenant).

Parâmetros do corpo

Campo	Valor	Descrição
grant_type	client_credentials	Valor fixo. É o fluxo que os clientes da API usam.
client_id	seu usuário	Usuário da Rently habilitado para a API.
client_secret	sua chave	Chave do usuário.

Resposta

Se as credenciais forem válidas, você recebe um JSON com o token:

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

Campo	Tipo	Descrição
access_token	string	O token a enviar em cada request.
token_type	string	Esquema de autorização. Sempre bearer.
expires_in	number	Segundos até a expiração (≈ 1 dia).

dica

Guarde o access_token e reutilize-o em todas as suas chamadas até que expire. Não peça um token novo a cada request: o token é válido durante o dia todo.

Usar o Bearer token

Em cada chamada à API você envia o token no header Authorization, com o esquema Bearer:

Authorization: Bearer {access_token}

Exemplo de um request autenticado contra um endpoint real da API. GET /api/branchoffices lista as filiais ativas:

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

Idioma da resposta

O query param ?language= controla o idioma da resposta (por exemplo ?language=es-AR). Se você omitir, usa-se o idioma padrão do seu tenant. Aceita tanto a cultura completa (es-AR) quanto o código de duas letras (es).

Todos os endpoints de negócio (/api/...) exigem este header. Você pode ver o detalhe de cada operação, seus parâmetros e suas respostas na API Reference →.

Expiração e renovação

O token vence aproximadamente um dia após ser emitido (expires_in ≈ 86399 segundos). Não existe um mecanismo de refresh token: quando o token expira, você simplesmente pede um novo repetindo o POST /auth/token com suas credenciais.

Se você enviar um token expirado, ausente ou inválido, a API responde 401 Unauthorized com um header WWW-Authenticate que aponta para o endpoint de token do seu tenant:

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

Estratégia recomendada

Guarde a data/hora em que pediu o token e renove-o de forma proativa antes de atingir o expires_in. Como alternativa reativa, diante de um 401 peça o token novamente e tente o request de novo.

Papel do tenant

O tenant é resolvido a partir do host da URL. Quando você obtém um token, o tenant correspondente a esse host fica embutido no token como um claim.

Em cada chamada de negócio, a API valida duas coisas:

1. Que o token seja válido e não tenha expirado.
2. Que o tenant do token coincida com o tenant do host da request.

Um token = um tenant

Um token emitido para um tenant não serve para outro. Se você reutilizar um token contra o host de um tenant diferente, a validação falha com 401. Solicite sempre o token no mesmo host onde fará as chamadas de negócio.

Além disso, emitir o token e autorizar cada endpoint são camadas separadas: o usuário deve estar habilitado para usar a API, e depois cada operação aplica suas próprias permissões. Se o seu usuário não tiver permissão sobre um endpoint, o request pode ser rejeitado mesmo que o token seja válido.

Resumo

• Token: POST /auth/token com grant_type=client_credentials, client_id (usuário) e client_secret (chave), como application/x-www-form-urlencoded, sobre o host do seu tenant.
• Resposta: access_token, token_type: "bearer", expires_in (≈ 1 dia).
• Uso: header Authorization: Bearer {access_token} em cada chamada a /api/....
• Expiração: ≈ 1 dia, sem refresh token; peça um token novo quando expirar.
• Tenant: o token fica vinculado ao host/tenant onde você o pediu; não o reutilize contra outro tenant.

Com o token em mãos, continue explorando os endpoints na API Reference →.