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.

Lead sources

Read as Markdown

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

Lead sources record how businesses and Deals arrive in your Portal and decide their clients' initial experience and ongoing self-service access.

Configure a Lead source

  1. List sources with source_channels.list, then read the selected source with source_channels.get and source_channels.get_settings.
  2. Create a business-signup-link or Referral API source with source_channels.create_configured, supplying the client's intake, matchmaking and direct-application choices explicitly.
  3. Use source_channels.configure_settings with the settings read's latest revision as expected_revision. Omitted choices stay unchanged. Check can_enable before enabling a client option; existing self-service and direct-application sources survive an administrator disabling new enabling.
  4. Use source_channels.configure_intake for its application definition and acknowledgement message. Existing applications, answers, Projects and Deals remain intact.

For signup links choose one experience: intake, self-service, direct applications, or all off. When switching, explicitly turn off the other options. Other legacy mixed configurations remain readable; intake takes initial-entry priority, followed by direct applications, matchmaking, then provider-led work. Turning client matchmaking off changes client access without deleting data or disabling the provider team's tools. API-key action permissions are separate.

API sources support business profile only, client intake, self-service matchmaking, or a direct application to your Portal. Read the source's API readiness before creating a business with POST /v1/businesses/ and source_channel_id. Follow returned application URLs to read the live contract and save answers separately. An omitted or null invite_client uses the source's invitation default; false suppresses invitations, while true sends during creation before subsequent answers are saved. Creating or configuring an API source through MCP does not issue credentials. An authorized human activates its restricted key in API setup; never request or expose tokens in conversation. The old source_channels.create contract starts intake on and optional client actions off; use configured creation for new setup. Provider-wide client settings are deprecated.

In-house and Marketplace sources are created by the system; partner sources come from partnerships. Marketplace and partner-referral client behavior and intake setup are read-only: these sources receive submitted applications rather than starting client onboarding. An In-house self-service setting lets clients start funding requests; it does not automatically create a Project or Deal when your team adds a business. When an existing client adds or connects another business through their Portal, Levr creates the client-added source on first use. It copies the same Portal's signup link with the most businesses, choosing the newest on a tie. Client choices, the intake form/message, and selected Deal Package copy once; later link changes do not propagate. Without a signup link, intake starts on and optional client actions off. Signup-link arrivals keep their own source. A Deal Package defines the application and delivery setup for new Deals. Direct applications require a lender receiving profile and can_enable=true; an old draft Deal or Deal Package does not establish eligibility. Use configure_settings for client behavior. Retired provider-wide client switches and the automatic-Deal toggle are unavailable through MCP; configure_intake only selects the form and edits its messages.

Remove a Lead source

When the user asks to remove a source, use source_channels.get_removal_options to check eligibility and affected counts. A signup source with activity needs a replacement chosen by the user. Removing it moves business and Deal attribution to that replacement, changing how reports group the activity; the businesses and Deals remain.

Use source_channels.review_removal with the chosen replacement, explain the returned effects, and obtain a second explicit confirmation. Then call source_channels.remove with the unchanged review token, revision, replacement, and user_confirmed: true. Reviews expire after ten minutes or when the reviewed source, activity, or replacement changes. Reuse client_request_id only for an identical retry, including a completed removal.

An unused Referral API source can be removed; this revokes its source-owned API credentials. API sources with attributed businesses or Deals cannot be removed. Signup links for a removed source should no longer be used. System sources cannot be removed, and partnership sources are managed through the Partnership tools.

You can also remove an eligible source in your Portal. Credential management remains on the source’s Portal page. Confirmation does not grant additional Portal permissions.

Available tools

source_channels.listList Lead sourcessource_channels.getGet Lead sourcesource_channels.create_configuredCreate configured Lead sourcesource_channels.createCreate Lead sourcesource_channels.review_removalReview Lead source removalsource_channels.configure_settingsConfigure Lead source client settingssource_channels.configure_intakeConfigure Lead source intakesource_channels.get_activity_summaryGet Lead source activity summarysource_channels.get_settingsGet Lead source client settingssource_channels.get_removal_optionsGet Lead source removal optionssource_channels.removeRemove Lead sourcesource_channels.updateUpdate Lead source