API CasusLegal

Connection

This is a REST API. Connect it to your application based on any LLM or to any HTTP client as an external tool that your model calls to search case law.

Base URL: https://lk.casus.legal

Authentication: header Authorization: Bearer cl_live_…

Format: JSON over HTTPS.

1. Get a key

1. Sign in to your Personal accountVia Telegram or by email and password, using the same account as for the bot and web chat.
   “API” section
2. Request access through “Messages”Describe the task and the expected volume of requests. Self-service issuance of new keys is disabled.
   Write to the administrator
3. Wait for the terms to be approvedThe administrator will advise on availability, limits and the procedure for obtaining a key. Save the key cl_live_… immediately: it cannot be recovered. Purchasing a chat plan does not provide API access.

2. First request

# Queries are written in Russian: the corpus is Russian-language.
curl -X POST https://lk.casus.legal/v1/search \
  -H "Authorization: Bearer $CASUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "договор энергоснабжения, фактическое потребление", "limit": 15}'

import os, httpx

client = httpx.Client(
    base_url="https://lk.casus.legal",
    headers={"Authorization": f"Bearer {os.environ['CASUS_API_KEY']}"},
    timeout=60,
)

r = client.post("/v1/search", json={
    "query": "снижение неустойки по статье 333 ГК",  # Russian query: reduction of a contractual penalty under Art. 333 Civil Code
    "limit": 15,
    "mode": "hybrid",
})
r.raise_for_status()
data = r.json()
for hit in data["results"]:
    print(hit["court"], hit["date"], hit["case_number"], hit["url"])

3. Endpoints

POST /v1/searchuses 1 request

Hybrid search. Uses 1 request only upon a successful response.

The response structure returns ready-made blocks organized by the hierarchy of courts. Build the response from these blocks rather than making a separate request for each court.

{
  "_response_format_hint": "…answer-format directive…",
  "constitutional_context": { "items": [ … ] },   // Constitutional Court
  "vs_guidance":            { "items": [ … ] },   // Supreme Court Plenum resolutions and reviews
  "latest_practice":        { "items": [ … ] },   // recent Supreme Court chamber rulings
  "vas_history":            [ … ],                // history: Supreme Commercial Court case law
  "results": [
    {
      "id": 12345, "court": "Economic Disputes Chamber", "date": "10.05.2024",
      "case_number": "305-ЭС24-12345", "title": "…", "snippet": "…",
      "score": 0.87,
      "url": "https://lk.casus.legal/case/12345?t=<token>"
    }
  ],
  "_supersession_alert": "…",   // when a superseded act and a current act both exist
  "expansion": { … }
}

GET /v1/cases/{id}free

Act card: details, sections (text by section), articles, hashtags and links url / url_md / url_docx. Use it for verbatim quotations from key acts. It does not consume quota.

curl https://lk.casus.legal/v1/cases/12345 \
  -H "Authorization: Bearer $CASUS_API_KEY"

4. Errors and limits

All errors are returned as JSON {"error": "<code>", "message": "…"}.

5. Best practices

• Keep the key on the backend only. Store it in environment variables or secrets, not in code, Git, or the client.
• Retries with exponential backoff. For 429 and 5xx retry with increasing delays: 2s, 4s, 8s.
• Cache act cards. The content GET /v1/cases/{id} is stable, and the call is free.
• Do not modify links. Field url is signed with a token valid for approximately 30 days. Pass it unchanged.

Configuring your LLM

The API returns raw materials: act cards, thematic blocks and a format hint _response_format_hint. The quality of the final response is determined by your LLM's system instruction. Below are principles for two scenarios, not ready-made prompts.

Scenario A. Chat response (case-law overview)

1. One search, a broad limit. One call is sufficient /v1/search with a meaningful query and limit 15–20: the hierarchy of courts is already returned in blocks. Do not split the topic into requests for each court.
2. Pass the model _response_format_hint. This is a built-in format directive; taking it into account brings the response noticeably closer to a reference overview.
3. Role: “reference source, not adviser”. List all relevant acts by hierarchy (priority to the Constitutional Court, recency to the Supreme Court, and the Supreme Commercial Court as history), without a final recommendation and without selecting the “only correct” position on the user's behalf.
4. Links strictly from the field url. Prohibit constructing the address from id and deleting the token ?t=: without it, the link will not open the text.
5. Use quotations sparingly. Retrieve verbatim quotations through /v1/cases/{id} only for 3–5 key acts. For the Constitutional Court, the required quotation is already in the inline field position. This is the main source of excess tokens.
6. From the results only. Prohibit reconstructing case law from memory: if it is not in the API response, it “does not exist in the database.”

Scenario B. Compiling a case-law catalogue

Objective: a collection or list of cases for export, without legal analysis.

1. Narrow the search with filters first. Have the model clarify the topic and apply filters court / act_type / tag / article / year_from–year_to: the catalogue will become relevant and compact.
2. Collection without analysis. For each act, take id, the details (court, type, date, case number) and url. Do not summarize or quote the acts in this mode.
3. Completeness through multiple requests. For a broad topic, make several /v1/search by subtopic, year or court, and merge the results, discarding duplicates by id.
4. Return a list, not a conclusion. The mode's output: a table or list with links url, which the user will filter themselves.
5. Clearly separate the modes. Clearly distinguish this mode from Scenario A so that the model does not drift into a detailed analysis when a collection was requested.