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.

Management Groups

Read as Markdown

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

Management Group branding is shared by its Portals. Start with management_groups.get_branding and use its current revision for each change. Keep the scope to the requested whitelabelling.

Complete the setup

  1. Upload the supplied logo and save the color. Review the requested portals with review_branding_application, then apply_branding_to_portals. Verify the branding was applied; saving group assets alone is not completion.
  2. Use prepare_domains for the requested web addresses. For standard addresses, supply base_domain only to get portal.<base_domain> and apply.<base_domain>. When branded email is requested, configure the sender separately through update_branding using changes.sender_domain, sender_display_name, sender_local_part, and reply_to_email.
  3. Read get_branding again, including after hostname corrections. Give every record from domains[].dns_records and email_sender.dns_records in an easy-to-copy format showing type, name, and target. Include the same complete records in any zone file. Include email records when branded email is requested or configured. If requested sender records are missing, finish sender setup before calling that plan complete. Domain-only setup does not require email.
  4. Once the user adds DNS, refresh_branding_status and call change_domain_lifecycle with lifecycle_action: "activate", the current revision, user_confirmed: true, and a unique client_request_id. An explicit whitelabelling request authorizes applying the supplied branding to the requested portal selection and activating the requested addresses when the reviewed scope matches. Domain activation affects the Management Group, so check that shared scope is covered; do not implicitly include other portals. Do not ask again just because setup is ready. Clarify changed or unclear scope; a status question alone does not authorize a new action.
  5. Inspect branding.domain_activation. Only active means the addresses are live. For waiting, allow retry_after_seconds, read again, and retry with a fresh revision and request ID within the session. Reuse an ID only for a lost response or the same completed attempt. Waiting does not schedule activation. If user action is needed or the session cannot keep waiting, explain what remains incomplete and the next step. Email verification does not block web activation; an unverified sender stays disabled.
  6. Once active, offer branding.frontend_links.open_portal unchanged. The link uses the browser's session to continue to the branded portal. A signed-out browser logs in first; never transfer MCP credentials into a browser URL.

Make DNS easy to copy

Keep names and targets exact and individually copyable. Never invent records or substitute targets. Honor returned proxied: false as DNS only.

If the DNS editor appends its zone to Name, give a relative name only for the confirmed DNS zone. The setup base domain may differ from that zone. For example, in the customer.example zone, portal.customer.example may need Name portal. The final saved hostname must be portal.customer.example, never portal.customer.example.customer.example. Keep the CNAME target unchanged.

For zone files, use full record names and CNAME targets with trailing dots, such as portal.customer.example., so imports cannot append the zone. Preserve TXT values with valid quoting. Identify the import zone only when confirmed; do not guess or replace unrelated records.

Related resources

Branding

View tools and requirements

Available tools