Authentication

The Rently API uses OAuth2 with Bearer tokens. The flow is simple: you request a token with your credentials, store it and send it in the Authorization header of every request. This guide covers how to obtain the token, how to use it, its expiration and the relationship between the token and your tenant.

The model in one sentence

You call POST /auth/token with your credentials and receive an access_token.
You send that token in the Authorization: Bearer {token} header on every call to /api/....
The token is bound to your tenant (your host) and expires after a day (expires_in ≈ 86399 seconds).

Credentials

Your client_id is your Rently username and your client_secret is your password. If you don't yet have a user enabled for the API, contact your Rently administrator.

Obtain the token

The token endpoint lives on your tenant's host and is called with grant_type=client_credentials. The body is sent as 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}"

Try it live

You can try this endpoint interactively —fill in your client_id, client_secret and your tenant's host, and send the request— in the reference: Get an access token.

The token endpoint lives on your tenant's host

https://{tenant}.rently.com.ar is used as an example. In production you must point both the token endpoint and the business calls to your tenant's host. The host identifies the tenant: the token it issues is bound to that tenant. Using the token against another tenant's host fails validation (see Tenant role).

Body parameters

Field	Value	Description
`grant_type`	`client_credentials`	Fixed value. It is the flow used by API clients.
`client_id`	your username	Rently user enabled for the API.
`client_secret`	your password	The user's password.

Response

If the credentials are valid, you receive a JSON with the token:

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

Field	Type	Description
`access_token`	string	The token to send on every request.
`token_type`	string	Authorization scheme. Always `bearer`.
`expires_in`	number	Seconds until expiration (≈ 1 day).

tip

Store the access_token and reuse it on all your calls until it expires. Don't request a new token on every request: the token is valid for the entire day.

Using the Bearer token

On every API call you send the token in the Authorization header, with the Bearer scheme:

Authorization: Bearer {access_token}

Example of an authenticated request against a real API endpoint. GET /api/branchoffices lists the active branch offices:

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

Response language

The ?language= query param controls the language of the response (for example ?language=es-AR). If you omit it, your tenant's default language is used. It accepts both the full culture (es-AR) and the two-letter code (es).

All business endpoints (/api/...) require this header. You can see the detail of each operation, its parameters and its responses in the API Reference →.

Expiration and renewal

The token expires approximately one day after it is issued (expires_in ≈ 86399 seconds). There is no refresh token mechanism: when the token expires, you simply request a new one by repeating the POST /auth/token with your credentials.

If you send an expired, missing or invalid token, the API responds 401 Unauthorized with a WWW-Authenticate header pointing to your tenant's token endpoint:

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

Recommended strategy

Store the date/time at which you requested the token and renew it proactively before expires_in is reached. As a reactive alternative, on a 401 request the token again and retry the request.

Tenant role

The tenant is resolved from the host of the URL. When you obtain a token, the tenant corresponding to that host is embedded in the token as a claim.

On every business call, the API validates two things:

That the token is valid and has not expired.
That the token's tenant matches the host's tenant of the request.

One token = one tenant

A token issued for one tenant does not work for another. If you reuse a token against a different tenant's host, validation fails with 401. Always request the token on the same host where you will make the business calls.

In addition, issuing the token and authorizing each endpoint are separate layers: the user must be enabled to use the API, and then each operation applies its own permissions. If your user does not have permission for an endpoint, the request may be rejected even if the token is valid.

Summary

Token: POST /auth/token with grant_type=client_credentials, client_id (username) and client_secret (password), as application/x-www-form-urlencoded, against your tenant's host.
Response: access_token, token_type: "bearer", expires_in (≈ 1 day).
Usage: Authorization: Bearer {access_token} header on every call to /api/....
Expiration: ≈ 1 day, no refresh token; request a new token when it expires.
Tenant: the token is bound to the host/tenant where you requested it; don't reuse it against another tenant.

With the token in hand, keep exploring the endpoints in the API Reference →.

The model in one sentence​

Obtain the token​

Body parameters​

Response​

Using the Bearer token​

Expiration and renewal​

Tenant role​

Summary​