LegalOn API is a RESTful API. Getting started takes the following three steps.
- Create API credentials (in the admin console)
- Obtain an access token (OAuth 2.0 Client Credentials)
- Call the API (send requests to
api_base_url/rest/v1)
Important:
- The token endpoint depends on your contracted region.
- The base URL for API calls is built using
api_base_urlreturned by the token response (append…/rest/v1as defined in the OpenAPI “Servers”).
API credentials can be created from the LegalOn admin console.
| Field | Description | Example / Options |
|---|---|---|
| Display name | A name used to manage your API credentials. Choose a name that clearly indicates the purpose. | prod-batch-integration / stg-test-client |
| Expiration | Expiration of the API credentials. Select according to your operational policy. | 7 days / 30 days / 60 days / Specify by day / No expiration |
Operational tip
Using a display name that includes “purpose + environment” makes it easier to audit credentials and assess impact when they expire.
Once created, the API credentials will be shown on the screen.
API credentials are displayed only at the time of creation and cannot be shown again.
Store them securely.
Access tokens are obtained using the OAuth 2.0 Client Credentials Flow.
curl -H "Authorization: Basic ${API_CREDENTIALS}" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-X POST ${api_base_url}/oauth/token${api_base_url}depends on your region.${API_CREDENTIALS}is the value issued in the admin console.
If the token request succeeds, the following response is returned.
- For subsequent API calls, send
access_tokenasAuthorization: Bearer <token>. - Use
api_base_urlfrom the token response as the API base URL (your API calls are based on{api_base_url}/rest/v1).
About expiration
The access token expires 1200 seconds (20 minutes) after issuance.
This value may change in the future. In your implementation, rely onexpires_in.
{
"access_token": "<ACCESS_TOKEN>",
"expires_in": 1200,
"token_type": "Bearer",
"api_base_url": "https://${api_base_url}"
}| Field | Type | Description |
|---|---|---|
access_token | string | Access token used to call the API |
expires_in | number | Token lifetime in seconds |
token_type | string | Token type (typically Bearer) |
api_base_url | string | Base URL for API calls |
- Access tokens are short-lived. If you receive
401 Unauthorized, obtain a new token first. permissionsare determined based on the privileges of the user linked to the API credentials (see FAQ for details).- Responses may include
X-Request-Id. We recommend logging it for support inquiries and troubleshooting.
The API base URL is {api_base_url}/rest/v1 (api_base_url is taken from the token response).
curl -X GET \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
${api_base_url}/rest/v1/users?page_size=50Depending on the result of the API call, the following responses are returned.
- The status code and response body defined by the target API are returned.
Implementation note (Forward compatibility)
The response body may be extended with additional fields in the future.
Implement your client so that it ignores unknown JSON fields (do not fail on extra fields).
- An appropriate status code and error information are returned depending on the cause.
Examples (common causes)
- Invalid access token (e.g.,
401 Unauthorized) - Invalid parameters (e.g.,
400 Bad Request) - Insufficient permissions (e.g.,
403 Forbidden) - Rate limit exceeded (e.g.,
429 Too Many Requests)
The following headers may be included in API responses.
| Header | Description |
|---|---|
X-RateLimit-Limit | Configured request limit |
X-RateLimit-Remaining | Remaining number of requests |
X-RateLimit-Reset | Seconds until the limit resets |
X-Request-Id | Unique identifier for each request (useful for support inquiries) |
Operational tip
If you receive429 Too Many Requests, wait and retry based onX-RateLimit-Reset.
When contacting support, includeX-Request-Id.
API calls are subject to rate limits. If you exceed the limit, the server returns 429 Too Many Requests.
In principle, all requests count toward the rate limit.
The following cases are not counted toward the rate limit.
- The Public API service is down (service-wide outage)
- The API access token is invalid
- The API access token has expired
- A rate-limit error (
429) has already been returned
Important
Even if a request fails, errors caused by unmet request conditions—such as permissions, parameters, or resource state—are counted as valid requests.
What should I do if my access token expires?
If the access token expires, send the token request again using your API credentials and obtain a new access token.
- Refresh tokens are not provided.
- If you receive
401 Unauthorized, try obtaining a new token first.
How are permissions in the access token determined?permissions are determined based on the privileges of the user linked to the API credentials.
- In the future, we plan to allow reflecting only the permissions selected when issuing the API credentials.
What happens if I send many requests in a short time?
If you send many requests in a short period, requests may be rejected due to rate limits (e.g., 429 Too Many Requests).
- Refer to
X-RateLimit-*headers and wait/retry accordingly.