Developers › Reference & tools
Developer Reference AI & tooling Machine-readable descriptions of this API, for codegen and for the AI that writes your integration. There are no SDKs, by design: the OpenAPI document is the client contract, and you generate from it.
Machine-readable API (OpenAPI) Point your codegen or coding assistant at this. Resource What it is Use it for /openapi.yaml OpenAPI 3.1 — every REST endpoint, request and response schema, auth and the problem+json error model Client generation, Postman, contract tests /llms.txt A curated map of the docs (the llms.txt standard): links and one-line descriptions An AI finding the right page fast /llms-full.txt The full documentation as one clean plain-text file Everything an AI needs to build an integration, in a single fetch /.well-known/oauth-authorization-server The authorization server's own metadata Every OAuth endpoint — read it at runtime; see Discovery Two surfaces are deliberately not in the OpenAPI document, and the document says so: the OAuth authorization server ( /idp/* ), which is described by its discovery documents, and the MCP endpoint ( POST /mcp ), which is JSON-RPC rather than REST and lists its own tools.
No SDKs, by design Generate a client from the spec; it is the contract we test against. LeadLogiX publishes no client libraries, and that is a decision rather than a gap. The REST surface is small, the spec is generated from the same source the server is checked against on every build, and a hand-written SDK in five languages would be five more copies of the contract to drift. A generated client is exactly as current as the spec you generate it from — regenerate when the Changelog says something changed. Generate # TypeScript: types for every path, operation and schema npx openapi-typescript https://<your-leadval-host>/openapi.yaml -o leadlogix.d.ts npm install openapi-fetch # Python: a typed client package pipx run openapi-python-client generate --url https://<your-leadval-host>/openapi.yaml import createClient from "openapi-fetch"; import type { paths } from "./leadlogix"; // generated above const api = createClient<paths>({ baseUrl: "https://<your-leadval-host>", headers: { "X-API-Key": process.env.LEADVAL_API_KEY }, }); const { data, error, response } = await api.POST("/api/v1/sessions", { body: { sessionId: "conv_9F3A21", processor: 2 }, // typed from the spec }); if (error) { // problem+json: branch on the stable code, never on the sentence console.error(response.status, error.code); } else { console.log(data.processing.state); // "QUEUED" } What a generated client does not give you Where it is The notify-then-poll loop — when to stop polling, and what each state means Session object → Processing states Retry rules: which codes to retry, and honouring Retry-After Ingestion errors & limits OAuth — use a standard OAuth 2.1 library against the discovery documents OAuth 2.1 / OIDC MCP — use any MCP client library; the tool list is served per token MCP → Hosted server
MCP is for runtime, not for writing code The two Model Context Protocol servers are for an agent calling LeadLogiX while it works , not for a coding assistant writing your integration. The hosted server reads a customer's workspace over OAuth; the local leadval-mcp package notifies and looks up with your own key. How they differ, and the only tool catalogue, are on MCP → Hosted server ; installing the package is on leadval-mcp (npm) . Routing an agent by opening hours is on Availability & hours .
Building an integration with an AI assistant The fastest path Give your AI coding assistant the OpenAPI spec ( /openapi.yaml ) and /llms-full.txt , and ask it to build the notify-then-poll flow. Both are grounded in the shipping API, so the generated code targets real endpoints, real auth, and the real error model. Need the Identity Resolution or Customer Profiles API schema, or a hand? Contact EVAS at support@evas.live . Building an OAuth client? Write the refresh logic yourself Assistants routinely generate retry-on-failure around a token refresh, and here that revokes the customer's whole grant — the rotation rule .