Skip to content
Skip to content

Use a Java or Kotlin client

How to call Compute from Java or Kotlin over REST with your existing HTTP client, and which API version to build against.

Updated

Use the REST contract to call Compute from Java or Kotlin. Your existing application or agent keeps its model, goal, project context and final decision; REST exposes the current operations. This page is REST guidance for JVM applications, not a JVM SDK package. Java and Kotlin callers use the remote contract at https://lithi.ai with an account key, as REST describes. A request is a remote assessment or quote or approved execution when the account has the required service access.

1. Choose an HTTP client

Use the HTTP client already supported by your Java or Kotlin application. The client matrix lists the released language clients; it does not list a Java or Kotlin SDK package, so there is no Maven or Gradle coordinate to use here. That package boundary does not limit direct REST integration.

2. Build against the HTTP contract

Use the current API description for method, path, scope, request, response, and error shape. It currently identifies OpenAPI 3.1.1 and API version 1.0.0.

The core customer REST flow includes:

  • POST /v1/quotes
  • POST /v1/jobs and GET /v1/jobs/{id}
  • POST /v1/jobs/{id}/cancel
  • GET /v1/jobs/{id}/events and /result
  • batch, artifact, capability, usage, receipt, and agent-event operations
  • bounded OpenAI/AWS compatibility translators

Every POST in this flow requires a stable Idempotency-Key, including cancellation. Responses use strict { "ok": true, "data": ... } success envelopes or the generated typed error envelope.

3. Preserve the REST contract in your wrapper

If you generate or hand-write a JVM adapter, preserve strict field behavior rather than relaxing it. Don't silently drop unknown fields, serialize credentials into payloads, infer an HTTP method or path from a generated class or wrapper name, or collapse the SDK error class and server error code into one string.

Keep HTTP API version, payload contract identity, and your own wrapper version separate. Treat generated source as your integration unless a separately evidenced Lithi JVM package is supplied to you.

Start with REST and the schema reference.

4. Keep local preparation and delivery with the caller

Your Java or Kotlin wrapper is a caller-owned wire client. It does not provide the TypeScript Kit's local record preparation, pseudonymization, compile/seal workflow or complete result-delivery steps. Do not treat a generated class or a package name as evidence of a released JVM SDK.

The JVM REST wrapper has no monthly-report operation in this guide. Reading that report needs separate permission and an approved reporting API or file path; it remains outside the five MCP work tools.

For the support-ticket preparation example, read What leaves your machine before sending any prepared input. Then use result verification and result delivery. The Kit helper reference lists the actual helper surfaces supplied by TypeScript and Python.

See Kit contents for the supplied modules and workflow guides.

Was this page helpful?