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.

Publish application form changes

Read as Markdown

All MCP tools

client_intake_application_editor.publish

Publish exactly the saved draft and participant effects reviewed by publish_review. This changes an existing application immediately and can permanently delete removed questions' submitted answers and file access. First establish intent, explain the reviewed question changes, affected stored data, selected participants and exact message, then request consent. Consent is required even with no participants. Pass the review's live_revision as expected_live_revision, draft_revision as expected_draft_revision and exact review_digest, recipient_ids and message. Use allow_destructive_changes only for expressly approved removals; unsupported conversions remain blocked. Communications include update notifications/emails and, with a message, shared messages and possible additional notifications/emails. Undo/reset cannot recall communications or restore deleted answers. Preserve client_request_id for identical retries; read get_config after success or any uncertain outcome before a new action. This toolset is available only by specific grant; access can be requested.

Operation
write
OAuth scopes
mcp

Availability depends on your assigned tools. Scopes do not grant record access. Read the tool description and current resource before changing it; follow the required revision and idempotency fields below.

Inputs

Name and descriptionRequired
allow_destructive_changesSet true only after explicit consent to the reviewed permanent answer deletion.No
business_idExact Business id from businesses.list or businesses.get in the selected provider workspace; do not pass an application or runtime ID.Yes
client_request_idUnique action key. Retry the identical call with this same key after an uncertain outcome.Yes
expected_draft_revisionCopy draft_revision from the same current action review.Yes
expected_live_revisionCopy live_revision from the current action review.Yes
messageOptional shared participant message. Review the same text before publishing.No
provider_slugProvider workspace returned by providers.list.Yes
recipient_idsExact recipient_id values from publish_review. Empty selects no communications; defaults are never applied.No
review_digestExact review_digest from publish_review for these recipients and message.Yes
user_confirmedSee the input schema for constraints.Yes
View exact input schema

Result

Check the structured result for success or an error before continuing. Read the affected record to confirm your change.

View exact output schema

For this workflow’s steps and prerequisites, read the Client intake application editor guide.