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.

Projects

Matchmaking

Find funding partners that may fit a business’s funding goal.

Read as Markdown · REST operations · MCP tools

Find funding recommendations

A project is a funding goal for a business. Its Criteria describe the request and help assess which funding partners may fit. Read and update those Criteria through the project’s matchmaking application operations. Matchmaking evaluates those Criteria and produces recommendations; it does not submit applications.

  1. Create or read the project for the business you are helping.
  2. Fetch its application contract and complete the Criteria. Read its answers and use the answers ETag for REST writes. You can use Autofill to prepare suggestions.
  3. Start matching with the reviewed expected_answers_revision and retain the returned run ID and URLs.
  4. Check progress while the run is queued or running. Settled statuses are completed, partially_complete, failed, and cancelled. Read failures before deciding whether to retry.
  5. Read the results and review fit, missing information, uncertainty, and recipient availability.
  6. Save selections if you want to keep your shortlist. To create a Deal, use the Business ID and copy the chosen result's recipient.id into recipient_id. Include the Project ID to keep the Deal linked to this funding goal.

Result classifications are match, partial_fit, insufficient_information, not_a_match, and not_assessed. An empty result list or missing-information assessment does not establish a suitable match. Check recipient availability before creating a Deal.

Use returned result IDs and package_version when saving selections. If is_stale: true, review the project and Criteria and start a new run. Do not silently reuse results assessed against outdated information.

Completed results remain stable when failed recipients are retried on the same run. Create one Deal per chosen recipient and retain each receipt.

The REST steps and file/Autofill guidance below use API keys. For MCP, follow the Matchmaking tool guide and use live discovery to find the project's Criteria, matching, result-review, and deal-creation tools. Do not infer MCP tool names from REST paths. The tool contract determines which current run or explicit run it reads.

Add repeated entries

The contract's repeatable_groups describe the allowed rows and their question keys. Use operations.repeatable_items_url to list or create rows. Use the returned item_id for updates, deletes, and answers inside that row. A row's position is not its ID.

These writes require the latest answers ETag and an Idempotency-Key. If answers change, read them again before retrying.

Attach documents

File bytes never belong in JSON. Request an upload through operations.file_uploads_url with the file question's block_key and, for a repeated entry, its item_id.

The response gives an expiring upload_url, exact multipart field name, and size limit. Upload one file part with the required If-Match and Idempotency-Key headers. Read operations.files_url afterward to confirm the file and obtain download URLs. Delete files using their returned file_id.

Resolve relative download URLs against the API origin and use the documented authentication. Read fresh metadata when a download URL expires.

Use Autofill to prepare answers

Autofill turns email text and documents into suggestions. It does not save application answers until you accept suggestions.

  1. Read Autofill preparation, add email text, and optionally upload supporting files. Use the latest preparation ETag after each change.
  2. Start a run with expected_preparation_revision set to the latest preparation revision. Keep its URL so you can resume monitoring.
  3. Check the run while it is pending or running. When it settles, read its suggestions and any warnings or failures.
  4. Review the proposed values, sources, and concerns. Accept only the suggestions you intend to save, using the latest answers revision.
  5. Read the application answers to confirm what was saved.

Preparation’s files list shows each supporting document’s name and processing status. Check it after an upload, or if the upload response was lost, before uploading the document again. A document is pending while queued, running while being read, success when ready for Autofill, or failed when it needs attention. Read preparation again to check progress; processing updates do not change its revision.

For scalar suggestions, the suggested answer is proposed_value.field_value. Compound proposals contain attributes; repeated-entry proposals contain list_items; file proposals contain file-source metadata. Review the complete proposal, then use the suggestion's acceptance operation to save it. You do not need to reconstruct an answer update from the proposal.

Treat numeric proposal metadata as opaque context. Write answers using the keys and repeated-entry IDs returned by the Application Contract.

Review one pending suggestion's proposed value, evidence, and concerns. Read the current answers, then POST to the Run's suggestions_url plus {suggestion_id}/accept/ with no request body, the answer ETag in If-Match, and a unique Idempotency-Key. Levr checks the answer revision and target drift, applies the proposal, and records acceptance in one transaction. A 412 means the answers changed; reread and review before issuing a new command. A 409 suggestion_conflict means the suggestion is stale, superseded, or already resolved; refresh suggestions and review again. An identical retry must reuse the original precondition and key. Check the returned suggestion is accepted and verify the intended value through the answers read. Use the returned ETag for the next answer mutation. Do not copy proposal metadata into an answer-update request to accept a suggestion.

A settled webhook tells you the run has finished processing. Review and accept its suggestions before submitting the application. Set a polling deadline and keep the run URL so you can check again later. Check warnings and can_retry before using the returned retry_url.