Use your existing coding agent
Let your existing coding agent select the customer-facing API from your project and prepare an OpenAPI artifact. Elva receives that API definition and creates a collection, draft contract, and draft MCP.
Preview: these commands require a compatible CLI build and Elva service support. Check elva --version and each command's --help output. Your installed release may not include every command shown here.
Set up the agent integration
elva agent setup --target all --user
elva auth login
Choose --target codex, claude, or all. Omit --user to install for the current project, or use --path DIRECTORY for another project. Reload the agent after setup. Existing files with different content and symlink destinations are refused; identical repeat installation is safe.
If you need a new Elva account, use elva auth signup --email you@example.com and enter the verification code in the requesting CLI.
Ask for a consumer API
For example: “Prepare an Elva artifact for partners to read their own orders and shipment status. Include only the required operations and response fields. Exclude internal notes, staff operations, source snippets, and real customer data. Use bearer authentication and show me the sanitized definition before creation.”
Your source stays with your existing agent and its configured provider. This workflow sends an API definition to Elva without an Elva AI source scan. Review what your agent writes into descriptions and schemas as carefully as the endpoint selection.
Validate and inspect locally
elva --json agent schema
elva --json agent validate --from artifact.json --out sanitized.json
version | 1 |
requestId | A fresh lowercase UUIDv4; retain it for retries of unchanged input. |
name | The human-readable consumer API name. |
audience | partner, public, or internal. |
auth | {"type":"bearer"}, {"type":"api_key","header":"X-API-Key"}, or an explicit {"type":"none"}. Never include tokens. |
spec | OpenAPI 3.0 or 3.1 containing only the intended operations and fields. |
Use one HTTP(S) server URL and local #/components/schemas/... references. Limits include 2 MiB, 400 operations, 40 nested levels, and additional bounded text and schema sizes described by agent schema. Offline validation does not replace the service's runtime compatibility check.
The sanitizer removes examples, defaults, vendor extensions, external and security metadata, and unused schemas. It preserves actual property names such as example. Secret-pattern checks cannot prove free text is safe; inspect sanitized.json for private fields, source snippets, local paths, Git URLs, and customer data.
Create resources
elva --yes --json agent create --from sanitized.json --plan-only --out review.json
elva --yes --json apply review.json
--plan-only imports the collection and saves a review, while deferring contract and MCP creation. Review the file before apply. To create drafts directly after reviewing the sanitized artifact, run agent create without --plan-only and --out.
The JSON result includes status, data, and next_action with resource IDs and recovery instructions. Every operation and field in the submitted spec enters the generated contract, so select the intended surface before submitting.
Recover and release
After interruption, retry with the same file and requestId to reuse the plan and resource IDs. Changed input, an expired plan after seven days, or a modified imported collection requires a newly reviewed artifact and requestId. Partial resources are not automatically deleted.
elva --yes --json contract publish CONTRACT_ID
Use the returned contract ID and complete required approvals. Verify the published tools with an authorized client. The upstream API must enforce customer and tenant access. If the artifact uses unsupported schemas, refine it locally rather than switching to a source-upload workflow without reviewing that different data-sharing choice.
On this page
- Use your existing coding agent