SDKs & Tools
The LXI API in your stack.
Use our Python and JavaScript clients or generate a typed client directly from OpenAPI 3.1.
Official Python SDK
Python 3.10+
from lxi_sdk import LXI
client = LXI() # liest LXI_API_TOKEN
print(client.domains())
print(client.domain_check("example.de"))Official JavaScript SDK
Node.js 18+ and modern runtimes
import { LXI } from "./index.js";
const client = new LXI({ token: process.env.LXI_API_TOKEN });
console.log(await client.usage());Typed clients
OpenAPI Generator
openapi-generator-cli generate \
-i https://lxi.be/openapi.json \
-g typescript-fetch -o ./lxi-clientThe specification defines operation IDs, input schemas, path parameters, security scheme, and structured errors. Generated clients should receive the token via their bearer auth hook.
Tool Discovery
Discoverable and limitable for AI agents
llms.txt, llms-full.txt and OpenAPI describe the public capabilities. Give agents their own tokens with minimal scopes and still require explicit confirmation for purchases or deletions in your agent workflow.
External tools
Connect your own services with Maker
Maker can use shared tools of a connected service as an MCP client. In the project, open the MCP section under Sources, enter the HTTPS address of the service and, if needed, save its bearer token. Then refresh the tool list.
Use a separate token with the narrowest possible permissions for each connection. Do not put credentials in the URL, in chat messages, or in project files. The connection applies only to this project and its owner.
This is an outbound integration: The connection does not itself make Maker an MCP server. Setup is currently done in the Maker browser, not via an additional CLI command.
Your approval decides
Set tool permissions and AI processing separately
Each tool is initially locked. You can confirm each individual call or approve the tool for automatic calls in the project. Pay particular attention to actions that change or delete data or incur costs.
The additional approval for AI processing allows tool descriptions, task parameters, and results to be sent to the AI model. Without it, only manual tool calls remain possible. A service's self-declaration that a tool is read-only does not replace approval.
With single confirmation, Maker shows the specific parameters. After approval, a waiting Maker run continues its work. Manually prepared calls can be executed separately in the tool dialog. Changes to a connection or tool definition may require new approval.
Traceable execution
Handling interruptions and unclear results
Calls remain bound to the user task and the reviewed project state. A retry does not automatically repeat an already completed or possibly executed action. When re-adopting a not yet sent call, a new single confirmation may be required.
If the status is “result unclear”, first check the connected service. Then document in the tool dialog whether the action was executed. This information is stored as your feedback, not as an independently verified result. Even entering “not executed” does not restart the original action.
Stopping does not prevent an external change that has already occurred and does not undo it. When credits are exhausted, no further agent call is started. A successful tool phase also does not replace the subsequent review of the generated application.
Integration profile
What the MCP client supports
Supported are publicly reachable HTTPS endpoints on port 443, tool lists, and tool calls via Streamable HTTP. Available are the stateless protocol profile 2026-07-28 and the explicitly selectable older profile 2025-11-25. Responses can be JSON or a limited SSE data stream.
Tool inputs are validated against their JSON schema. Local schema references are possible; external schema files are not loaded. Redirects, local network addresses, and credentials in URLs are not allowed.
- Up to 16 connections per project and 64 tools per connection.
- Up to 128 KB per request and 1 MB per response; calls have a time budget of 120 seconds.
- A tool phase has 32 steps by default. A maximum of 32 stored actions are provided per user task, including across retries.
- Large tool descriptions and results are provided page by page.
Not supported are OAuth login to the MCP service, stdio processes, resources, prompts, and interactive follow-up questions from an MCP server. A service that requires additional input is therefore not considered successfully completed.
Autonomously generated Infinity cycles do not perform external MCP actions. Specific queued user tasks use the normal project approvals.
Your development workflow
Connect Maker projects with GitHub
The internal version history works without Git. If you want to work with a repository, open the project settings and connect an initialized GitHub repository with an existing branch. Use a dedicated token limited to this repository.
For exports, the token needs read and write permissions on repository contents, and additionally the corresponding pull request permissions for pull requests. Changes to GitHub workflow files may require additional permissions. Your repository's rules and protected branches remain in effect.
Import external changes into Maker first. For file conflicts, choose the desired version; adoption only happens after review. Git credentials belong exclusively in the token field, not in chat or project files.
Develop changes separately
Transfer a reviewed state to a new branch
Open “Branches & Pull Requests”, choose a new branch name, and prepare the operation. Check repository, source commit, and file versions before confirming execution. The new branch contains the finished commit; existing branches are not replaced.
With “Adopt branch” you can then explicitly make the created branch the target for future imports and exports. This selection changes neither the project files nor your internal version history.
Team review
Create a pull request as a draft
First transfer the current reviewed state to the connected branch. Then prepare a pull request to your target branch, add title and description, and confirm the displayed operation. Maker compares the exported files with the approved state.
The pull request is created as a draft. Review, GitHub CI, and merge remain separate steps. A created pull request does not mean your repository's checks have passed. An identifier in the description helps to find the original operation after a connection interruption.
Traceable handovers
Check unclear results instead of sending twice
Stored operations remain visible after closing the browser. For “result still unclear”, select “Check status on GitHub”. Maker looks for the original action without executing it again. If the target has since been changed or deleted, an additional check directly on GitHub may be necessary.
You can withdraw an approval that has not yet been sent. Changes already made on GitHub are not undone by this. A project state changed in the meantime or a new connection may require new approval.
Git exports are limited to 10 MiB per file and 50 MiB in total. The directory .lxi/ is reserved for export metadata.
Terminal and automations
Branches and pull requests via CLI
From CLI 1.1, you use the same stored Git operations as in Maker. First connect the repository in the project settings. Your LXI token needs maker and additionally maker_git. The additional permission is not automatically assigned to existing tokens.
lxi auth login --scope maker --scope maker_git
lxi --json maker git prepare-branch PROJECT_UUID --target feature/task-menu --operation-key task-menu-1
lxi --json maker git status PROJECT_UUID OPERATION_ID
# Erst Repository, Dateistand, Ziel und request_hash prüfen:
lxi maker git execute PROJECT_UUID OPERATION_ID --request-hash REVIEWED_HASH --confirm
# Separat als verbundenen Branch übernehmen:
lxi maker git adopt PROJECT_UUID OPERATION_ID --request-hash REVIEWED_HASH --confirm
lxi maker git prepare-pr PROJECT_UUID --target main --title "Task menu" --operation-key task-menu-pr-1
You then review and confirm the newly prepared pull request as a separate operation. The CLI does not assume approval, does not perform a merge, and does not automatically retry a write request.
At git_operation_unconfirmed or the state unknown first read the stored operation and compare with lxi maker git reconcile PROJECT_UUID OPERATION_ID . A response may be absent after 60 seconds while the action continues to run. This is not confirmation that nothing has happened.
If the response with the identifier is missing after preparation, you may repeat only this preparation with the same operation_key and unchanged inputs. list shows the last 30 operations; cancel withdraws only approvals not yet sent. With --json you get records on stdout and structured errors on stderr. Always check the field state.
REST base: /api/v1/maker/projects/{project_id}/git/operations. GET lists operations, POST prepares one. Under /{operation_id} you read the status; POST to /execute, /adopt, /cancel or /reconcile executes the named action. Execution and adoption require request_hash and confirmed: true. Input schemas and errors are in OpenAPI documented.