API Integration Guide

Lither exposes a REST API so you can connect your own systems to fleet data, AI agents, workflow automation, and operational records. This guide covers the concepts you need to integrate confidently: authentication, endpoints, real-time events, pagination, error handling, and security. For exact endpoint paths, field names, and current limits, always treat the official documentation as the source of truth.

Authentication and API keys

Access to the API is granted through API keys, which you generate and manage from your workspace. A key identifies your integration and authorizes it to act on your behalf, so treat it like a password. The conventional pattern for a REST request is to pass the key in an HTTP header. As an illustrative example only, a request typically carries an authorization header of the form Authorization: Bearer YOUR_API_KEY. The exact header and the URL you call are documented in the docs.

Keys are scoped using role-based access control, so an integration only receives the permissions it actually needs. When you create a key for a narrow task, grant it the minimum scope required rather than full account access. You can learn more about how scoping works on the RBAC and API Connections pages.

Working with endpoints

The API follows standard REST conventions. Resources are addressed by URL, you act on them with HTTP verbs such as GET to read, POST to create, PATCH or PUT to update, and DELETE to remove, and request and response bodies are encoded as JSON. Set a Content-Type: application/json header when you send a body.

A practical first step is to make a single authenticated read request and confirm you receive a valid JSON response and a 200 status. From there you can map the resources you need to your use case. The full catalog of available resources is listed on the Endpoints overview and detailed in the documentation, including the precise paths and the fields each resource returns.

Webhooks versus polling

When your integration needs to react to something that happens inside Lither, you have two broad options.

• Polling means your system calls an endpoint on a schedule and checks whether anything changed. It is simple to build and works anywhere, but it adds latency and wastes requests when nothing has changed.
• Webhooks reverse the direction: Lither sends an HTTP request to a URL you control the moment an event occurs. This is more efficient and closer to real time, at the cost of running an endpoint that can receive and verify incoming calls.

As a general rule, prefer webhooks for event-driven work such as status changes and completions, and fall back to polling only where a webhook is not available or your environment cannot accept inbound traffic. Make your webhook handler idempotent, since the same event may be delivered more than once, and return a fast success response so the sender does not retry unnecessarily. See Webhooks and the deeper comparison in webhooks versus polling.

Rate limits, pagination, and error handling

Like most production APIs, Lither applies rate limits to keep the platform stable for everyone. The specific limits live in the documentation, but the best practices are universal. Read any rate-limit information returned in response headers, back off when you are throttled rather than retrying immediately, and use exponential backoff with jitter so many clients do not retry in lockstep. Industry guidance widely recommends batching work and caching responses you can reuse to stay comfortably under any ceiling.

List endpoints return results in pages rather than all at once. Always follow the pagination mechanism described in the docs instead of assuming a fixed page size, and keep requesting pages until none remain. Never hard-code a total count.

For error handling, rely on HTTP status codes: a 2xx means success, a 4xx means your request needs fixing such as a missing field or an invalid key, and a 5xx means a server-side problem you can safely retry with backoff. Read the JSON error body for a machine-readable reason, log it, and surface a clear message to your users rather than failing silently.

Security best practices

Treat API keys as secrets. Store them in environment variables or a secrets manager, never in client-side code, version control, or logs. Always call the API over HTTPS so credentials and data are encrypted in transit. Use separate keys for different integrations and environments so you can revoke one without breaking the rest, and rotate keys periodically.

When you receive webhooks, verify that each request genuinely came from Lither before acting on it, and only accept calls over HTTPS. Because Lither is EU-hosted, scope your keys tightly and request only the data your integration needs, which keeps your processing footprint small and supports your compliance obligations. Ready to build? Create an account and open the documentation, or contact us if you need a hand planning your integration.