Skip to content
Levr API Documentation
Download OpenAPI specOpenAPI

Hand off to an AI agent

Copy instructions to your AI agent

Copy this guide into your AI agent. It links to the current REST API and MCP documentation.

You are helping someone integrate their system with Levr. Use Levr's published documentation and machine-readable contracts as the source of truth. Do not invent endpoints, fields, or MCP tools.

  1. Start with the Levr API documentation to choose between a server-to-server REST integration and a user-authorized MCP connection.
  2. For REST, read the Markdown REST API guide, choose the user’s task, then fetch only the relevant resource guide and operation Markdown. Resource indexes include task guidance. For funding recommendations, start with the Matchmaking guide. Use the OpenAPI specification for exact paths, authentication, parameters, and envelope schemas.
  3. For REST client intake, Deal applications, or project Criteria, fetch that resource's contract_url. Its Application Contract is the authority for the current questions, stable keys, repeatable groups, file-transfer steps, accepted answer shapes, conditional visibility, supported operation URLs, and integration instructions. Repeatable fields require the returned item_id. File bytes use the expiring upload_url and multipart field named file; they never belong in JSON. Do not substitute a static example or the latest application definition.
  4. For an AI client acting with a signed-in user's access, read the MCP connection instructions in Markdown first, then the Model Context Protocol guide if needed. Let the connected MCP server expose its current tools and input contracts; do not infer tools from the REST API. Read the relevant MCP resource guide and follow the discovered tool’s revision, file-transfer, and confirmation requirements.
  5. Use URLs from the record handoff when supplied; otherwise use this documentation environment. Keep API keys and file-transfer credentials out of browser code, logs, prompts, and source control.
  6. Before implementing a write, verify authentication, required inputs, idempotency, error responses, and retry guidance in the current contract. If an operation is not documented, do not assume it exists.

Early access

Request an integration

Tell us what your integration needs to do. Add an email if you want a reply.

Release notes

Changelog

New capabilities and changes to the API, MCP tools, and documentation.

Check these notes when updating your integration. Breaking changes include the action you need to take.

Upcoming

Section titled “Upcoming”

  • REST API: Deal readiness checks the same lifecycle, application, and delivery requirements as submission. Application creation, update, and submission webhooks follow the owning Deal workspace and no longer depend on sharing the application.

  • REST API: Business profile is the baseline for all source starting experiences. Added client matchmaking settings and an existing-Project funding request operation, so integrations can enable client participation after creating a business and Project. Intake creation now returns application API links. Guides show the explicit follow-up flows.

  • REST API: Client intake application write access now includes submission. Readiness returns a submission_token for submitting the checked form and answers. Existing submission-only grants and revision-based requests remain supported. Added a dedicated intake completion guide covering edits, uploads, client handoff, and submission.

  • REST API: Deal application readiness now returns a submission_token. Submit it with an Idempotency-Key to protect the checked application and answers without managing two revisions. Existing revision-based submission requests remain supported.

  • REST API: deal_applications:write now authorizes completing and submitting Deal applications. Existing keys with this permission gain submission access. Existing submission-only grants remain supported; new keys use the consolidated permission. Submission no longer requires sharing the application or sending a client invitation.

  • REST API: Deal application sharing accepts access_mode: "edit" per recipient for completing and submitting the branded form. Omitting it retains view-only access.

2026-09

Section titled “2026-09”
  • MCP: Added deal_applications.check_submission_readiness to check whether a Deal Application is ready to submit. Returns blocking validation issues including missing fields, invalid values, and authorization requirements. Available in both read and edit tool sets.
  • MCP: Added client_intake_applications.check_submission_readiness for Client Intake Applications with the same contract.
  • REST API: Added GET /v1/deal-applications/{id}/submission-readiness/ and GET /v1/client-intake-applications/{id}/submission-readiness/ returning the same validation issue contract.
  • REST API: Added POST /v1/deal-applications/{id}/share/ and POST /v1/client-intake-applications/{id}/share/ for API-key-authenticated application sharing.

2026-08 — Early access

Section titled “2026-08 — Early access”
  • MCP: Added Portal activity summaries, business and Deal details, and Marketplace information.
  • MCP: Added feedback.request_feature for explicitly requested product feedback.
  • REST API: Added the initial guide and reference foundation.
  • MCP: Added connection guidance for user-authorized AI clients.
  • Documentation: Added environment-specific contracts, accessible navigation, and stable per-operation URLs.