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.

Deal applications

Read as Markdown

Choose an action to read its inputs, results, and usage guidance. Your connection determines which tools are available to you.

A Deal application collects the information required for one recipient. Find its ID through deals.get or a deals.create receipt. Each recipient can require different questions and documents.

Complete the application

  1. Read the application and its current question contract. Use the returned question keys, repeated-entry IDs, and supported tools.
  2. Read the current answers. Use their revision for answer changes; the application's own revision protects a different change.
  3. Update ordinary answers with the answer-update tool. Use dedicated tools for repeated entries and documents.
  4. Read readiness to find missing or invalid answers. Complete those questions before submission.

Attach documents

Call the application's prepare_answer_file_upload tool with the question key, latest answers revision, filename, byte count, and SHA-256 digest. Include the returned item ID for a repeated entry. POST the file to the returned URL as multipart field file, using transfer_token as a Bearer credential within five minutes. No separate API key is needed. Check the receipt, then list the files to confirm the upload. Files can be up to 25 MiB; application storage limits also apply.

Work with an uploaded document

List the application's files and use the returned file ID. Call deal_applications.update_answer_file with a filename, the latest expected_answers_revision, and a UUID idempotency_key to rename it while preserving its contents and identity. Renaming does not convert its format.

Call deal_applications.get_answer_file_download to retrieve the original. GET download.url with download.transfer_token as a Bearer credential within five minutes; no API key is needed. Downloads recheck current access and file availability. Unrelated answer edits do not invalidate the download. Keep credentials and bytes out of logs and messages. Uploading a processed copy adds another file; delete the original only if the user explicitly requests removal.

Use Autofill

Autofill proposes answers from evidence; it does not save them automatically. Read preparation to choose available evidence and add notes. Upload any new supporting documents before starting a run:

  1. Call deal_applications.prepare_autofill_file_upload with the latest expected_preparation_revision, a new UUID idempotency_key, filename, byte count, and SHA-256 digest of the file.
  2. POST the document as multipart field file to the returned URL within five minutes. Set Authorization: Bearer <transfer_token>; your MCP connection authorizes the upload, so no API key is needed. The limit is 25 MiB per file.
  3. Check the upload receipt and read preparation again. Use its latest revision when adding another document or starting Autofill.

An identical retry with the same transfer credential returns the original receipt without adding another file. Keep the upload receipt and use preparation’s files list to confirm the document names and follow processing. If the credential expires before you confirm the upload, read preparation and check that list before uploading again. A document’s status is pending while queued, running while being read, success when ready for Autofill, or failed when it needs attention. Processing updates do not change the preparation revision; read preparation again to check progress. Supporting documents provide evidence for Autofill; they do not fill an application question by themselves.

Start a run using the latest preparation revision, check its status until it settles, and review its suggestions. Accept only approved suggestions using the latest expected_answers_revision. Keep the revision and idempotency key for an identical retry, then read the answers to confirm what was saved.

If a revision is stale, read again and reconcile the change before retrying. Keep file-transfer credentials and document bytes out of tool arguments, logs, and messages.

Submit when ready

Read readiness and the current answers. Your AI must explain validation and any external-delivery effects, then obtain a second explicit confirmation before submission. Give both confirmations in your AI conversation. Read the application afterward to confirm the result. A submission receipt does not prove approval or funding.

Record an application decision

Use deal_applications.review_status_change to review an available status change and its effects. Source and processing Portals can record outcomes; observers can only record submitted or not-submitted status when available. Explain the review, obtain a second explicit confirmation, then call deal_applications.change_status with the same application, target status, optional destination stage, and review token. Send user_confirmed: true, a new UUID idempotency_key, and selected recipients’ email and origin, or recipients: [] for no optional messages. Automatic effects still apply.

Before marking funded, complete the required financing fields available to you. Read financing terms, then use Update financing terms for amounts and equipment details with the returned revision. Send equipment in changes.equipment_entries as the complete list you want to keep; [] clears it. If funding is confirmed before you have the funded amount, include allow_missing_funded_amount: true in both the review and execution calls. It defaults to false; other required fields and invalid amounts still block the action. Keep its value unchanged after review; changing it requires a new review and confirmation. Add the funded amount later with Update financing terms.

The review shows the stage change in your Portal, including any default stage it will create. Other Portals follow their stage synchronization preferences.

Marking funded may create commission obligations. Recording submitted status or reopening does not deliver the application. Read the application afterward to confirm its status.

Available tools

deal_applications.getRead a Deal Applicationdeal_applications.get_contractRead a Deal Application contractdeal_applications.get_answersRead Deal Application answersdeal_applications.update_answersUpdate Deal Application answersdeal_applications.list_repeatable_itemsList a Deal Application repeatable itemsdeal_applications.add_repeatable_itemAdd a Deal Application repeatable itemdeal_applications.update_repeatable_itemUpdate a Deal Application repeatable itemdeal_applications.delete_repeatable_itemDelete a Deal Application repeatable itemdeal_applications.get_answer_file_downloadGet a Deal Application original filedeal_applications.list_answer_filesList a Deal Application answer filesdeal_applications.get_file_textRead application document textdeal_applications.prepare_answer_file_uploadPrepare a Deal Application answer file uploaddeal_applications.update_answer_fileUpdate a Deal Application file metadatadeal_applications.delete_answer_fileDelete a Deal Application answer filedeal_applications.review_status_changeReview application statusdeal_applications.change_statusChange application statusdeal_applications.share_with_businessShare Deal Application with businessdeal_applications.get_autofill_preparationRead Deal Application autofill preparationdeal_applications.prepare_autofillPrepare Deal Application autofilldeal_applications.prepare_autofill_file_uploadPrepare Deal application Autofill supporting-file uploaddeal_applications.start_autofillStart Deal Application autofilldeal_applications.get_autofillGet Deal Application autofilldeal_applications.list_autofill_suggestionsList Deal Application autofill suggestionsdeal_applications.accept_autofill_suggestionAccept a Deal Application autofill suggestiondeal_applications.retry_autofillRetry Deal Application autofilldeal_applications.check_submission_readinessCheck Deal Application submission readinessdeal_applications.submitSubmit Deal Application