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.

Business guides

Create a funding request and find matches

Read as Markdown

Create a business in the receiving Portal, open a linked funding request, and supply Criteria to find funding options. An internal integration or an external referrer can perform these steps with the required API permissions and source access.

The result: this flow creates a business, a Project linked to a client-visible funding request, and a matching run. Matching does not submit lender applications or guarantee a suitable match.

A Project is the receiving team's workspace for a funding goal. Its linked funding request is the client's view of that goal. Both use the same matching answers, called Criteria.

The source initializes client matchmaking access on the business relationship. Creating the business alone does not create the funding request or populate Criteria; those are separate steps below. For an existing business from another starting experience, enable client matchmaking through the API, then continue at step 4. Compare starting experiences.

1. Prepare the source

A Lead source chooses how incoming businesses get started. The API calls it a source channel; pass its ID as source_channel_id when creating a business. Its settings determine whether business creation also starts an application. Application answers are always saved separately.

The receiving Portal is the workspace associated with your API key. Ask its administrator or your integration contact for:

  • An API source ID (srcch_…) configured as Clients start with self-serve matchmaking, plus a link to that source in the Portal.
  • Your environment’s API origin and a Portal API key scoped to the source with lead_submissions:write, projects:write, project_criteria:write, and project_matching:write.
  • Confirmation that the source is ready and the Portal has a default business pipeline and stage. Client matchmaking, funding-request creation, and the receiving team’s matchmaking tools must be available. Published recipient Criteria must be available for matching. The receiving Portal must remain the business’s source owner with a live client relationship.
Configure the source if you have Portal access

With permission to manage the source, open the Lead source, then Overview → Getting started → Change setup, and choose Clients start with self-serve matchmaking. For a new source, choose API integration when creating it. Confirm the matchmaking and funding-request capabilities listed above with the Portal administrator.

The source’s API setup section contains its ID and integration instructions. If a choice is locked, follow the restriction message and contact your administrator. A source-scoped key can also discover its IDs through the API root.

Create the source through the API instead

With source_channels:write, POST the following body to /v1/source-channels/ with your bearer key and a new Idempotency-Key. Save the returned id as SOURCE_ID. Check readiness in the response to confirm that the source’s form and routing are ready.

{"name":"Website enquiries","starting_experience":"matchmaking"}

starting_experience is required when creating a source. To find an existing source, use List Lead sources with source_channels:read.

2. Check the source setup

Use your environment's API origin and a server-side bearer key; Get started explains authentication. All requests below include Authorization: Bearer <API_KEY>. JSON writes also include Content-Type: application/json and a unique Idempotency-Key. Retain each write's key and body for retries.

Examples use illustrative IDs. Responses show only the fields needed for the next step; use the actual IDs and URLs returned by your API.

Request

GET /v1/source-channels/srcch_example/

Response · selected fields

{
  "starting_experience": "matchmaking",
  "readiness": { "is_ready": true }
}

Confirm starting_experience is matchmaking and readiness.is_ready is true. If the setup differs, confirm the source with the receiving Portal's administrator before creating records.

3. Create the business

Business creation uses the same payload structure for every starting experience. Send the source ID and contact details:

POST /v1/businesses/
Idempotency-Key: website-lead-12345-business
{
  "source_channel_id": "srcch_REPLACE_ME",
  "business": {
    "name": "Cedar Ridge Engineering Ltd.",
    "primary_contact_name": "Maya Chen",
    "primary_contact_email": "maya@example.com",
    "primary_contact_phone": "+16045550123"
  },
  "invite_client": false
}

invite_client: false suppresses the invitation. true sends it during creation, before subsequent answers are saved; omission or null follows the source's invitation setting. To save Criteria before inviting, keep it false and arrange the invitation through the receiving team's Portal afterward.

Response · 201, selected fields

{
  "business": {
    "id": "biz_example",
    "url": "https://YOUR_API_HOST/v1/businesses/biz_example/"
  },
  "starting_experience": "matchmaking",
  "client_intake_application": null,
  "deal": null,
  "deal_application": null
}

Save business.id before continuing. An identical retry returns the original result; a new key can create another business. Application answers belong in later requests. If returned, invitation_url is a private client access link.

4. Create the linked funding request

Create a project for this funding goal. create_funding_request: true also creates a linked funding request in the client's Portal (called a service request in API fields). To run matching only in your Portal, omit this field; client matchmaking access is not required for a private Project.

Request

POST /v1/projects/
Idempotency-Key: website-lead-12345-equipment-project
{
  "business_id": "biz_example",
  "name": "Equipment expansion",
  "target_amount": "250000",
  "target_currency": "CAD",
  "create_funding_request": true
}

Response · selected fields

{
  "id": "proj_example",
  "service_request_id": "srq_example",
  "contract_url": "https://YOUR_API_HOST/v1/projects/proj_example/matchmaking-application/contract/",
  "answers_url": "https://YOUR_API_HOST/v1/projects/proj_example/matchmaking-application/answers/"
}

Save both IDs. The Project and funding request share Criteria and matching work. Creation sends no invitation and does not expose private Project notes.

Already have a project? Add its client funding request rather than creating a second Project.

Already have a funding request for this goal? With businesses:read, discover it through business activation, then create the Project using only business_id and service_request_id to link that existing request.

5. Complete Criteria and find matches

Continue with Find funding recommendations, using proj_example as your Project ID. That walkthrough covers:

  1. Reading the Project's questions and saving Criteria.
  2. Attaching supporting documents.
  3. Starting matching and polling for results or receiving a webhook.
  4. Reviewing results, saving a shortlist, and creating a Deal for a selected recipient.
  5. Continuing to the shared Deal guide to complete and submit its application.

You need deals:write to create Deals after matching, and deal_applications:write to complete and submit their applications. Saving a shortlist alone does not create or submit a Deal.

In the receiving Portal, open Projects → Equipment expansion to review Criteria and results. A client with access can continue the linked funding request. This example left invitations off; arrange any client invitation through the receiving team.

You've finished when the linked Project and funding request exist and you have completed the matching or Deal workflow required by your integration.

If a step fails

ResponseNext action
401, 403, or record not foundCheck the environment, ID, key permissions, and source scope.
409 source_channel_not_readyAsk the administrator to resolve the reported source setup problem, then read the source again.
412 on an answer writeRead the latest answers, reconcile concurrent edits, and use their new ETag.
409 on a retryCheck whether the body or precondition changed. Reuse a key only for the identical command.
Validation errorCorrect the named field against the creation schema or the application's live contract.

After a connection failure, retry the same endpoint with the same key and body; the operation may already have succeeded. Save progress after each step so an answer-write failure never causes another business to be created.