How to Configure Custom OpenAI-Compatible Endpoints for AI Summaries in Meetily

Meetily routes AI summary requests to any OpenAI-compatible service by accepting a custom endpoint URL at runtime via the builtin_ai_generate_summary Tauri command, which constructs the request target in llm_client.rs by appending /chat/completions to your provided base URL.

Meetily is an open-source meeting assistant built with React and Tauri (Rust) that generates AI summaries from transcripts. Unlike tools that hard-code API endpoints, Meetily's architecture allows you to configure custom OpenAI-compatible endpoints for AI summaries, enabling integration with private proxies, Azure OpenAI, or self-hosted models like vLLM.

Architecture Flow

The configuration path follows a clear three-layer pipeline:

1. Frontend invocation – Your React component calls the Tauri command builtin_ai_generate_summary
2. Command routing – The Rust backend in frontend/src-tauri/src/summary/summary_engine/commands.rs validates parameters and forwards them to the LLM client
3. Request construction – frontend/src-tauri/src/summary/llm_client.rs builds the final HTTP request URL by trimming trailing slashes from your endpoint and appending /chat/completions

This design ensures the endpoint is never baked into the binary; you supply it dynamically with each summary request.

Step-by-Step Configuration

Select the Custom OpenAI Provider

When invoking the summary command, you must specify the provider type as custom-openai (mapped to LLMProvider::CustomOpenAI in the Rust backend). This signals the system to expect a third-party endpoint rather than the default OpenAI URL.

Pass the Custom Endpoint

The TypeScript frontend must include the customOpenAIEndpoint parameter when calling the Tauri command:

import { invoke } from '@tauri-apps/api/tauri';

async function generateCustomSummary(
  transcript: string,
  apiKey: string,
  endpoint: string
) {
  const summary = await invoke<string>('builtin_ai_generate_summary', {
    provider: 'custom-openai',
    modelName: 'gpt-4',
    apiKey,
    systemPrompt: 'Summarize this meeting concisely.',
    userPrompt: transcript,
    customOpenAIEndpoint: endpoint,  // Your custom URL
    maxTokens: 1024,
    temperature: 0.7,
    topP: 0.9,
  });
  
  return summary;
}

Persist Settings (Optional)

Meetily stores user preferences in a JSON configuration file within the app-data directory. To persist the endpoint, write to the settings store under the key summary.customOpenAIEndpoint. The UI subsequently reads this value and passes it as the customOpenAIEndpoint argument to builtin_ai_generate_summary on future invocations.

Backend Implementation Details

The Tauri command builtin_ai_generate_summary defined in frontend/src-tauri/src/summary/summary_engine/commands.rs accepts the endpoint as an Option<String> and forwards it to the core generator:

#[tauri::command]
pub async fn builtin_ai_generate_summary(
    provider: String,
    model_name: String,
    api_key: String,
    system_prompt: String,
    user_prompt: String,
    custom_openai_endpoint: Option<String>,
    // ... additional parameters
) -> Result<String, String> {
    let provider = LLMProvider::from_str(&provider)?;
    let client = reqwest::Client::new();

    summary::llm_client::generate_summary(
        &client,
        &provider,
        &model_name,
        &api_key,
        &system_prompt,
        &user_prompt,
        None,                       // ollama_endpoint
        custom_openai_endpoint.as_deref(),
        max_tokens,
        temperature,
        top_p,
        None,                       // app_data_dir
        None,                       // cancellation token
    )
    .await
}

URL Construction Logic

In frontend/src-tauri/src/summary/llm_client.rs (lines 173–179), the actual request URL is constructed dynamically when the provider is CustomOpenAI:

let url = format!(
    "{}/chat/completions",
    endpoint.trim_end_matches('/')
);

This logic normalizes your input by removing trailing slashes before appending the standard OpenAI chat completions path, ensuring compatibility with endpoints that may or may not include a trailing slash in their base URL.

Summary

• No hard-coded endpoints: Meetily accepts the custom URL at runtime via the customOpenAIEndpoint parameter
• Standard OpenAI compatibility: The backend appends /chat/completions to your base URL, supporting any service matching the OpenAI API specification
• Provider type: Must be set to custom-openai (Rust enum CustomOpenAI) to activate custom endpoint mode
• Key files: Configuration flows through frontend/src-tauri/src/summary/summary_engine/commands.rs and frontend/src-tauri/src/summary/llm_client.rs
• Persistence: Store the endpoint in Meetily's JSON settings to avoid passing it manually with every request

Frequently Asked Questions

Does Meetily support Azure OpenAI Service?

Yes. Since Azure OpenAI provides an OpenAI-compatible API, you can configure custom OpenAI-compatible endpoints for AI summaries in Meetily by setting your Azure endpoint (e.g., https://your-resource.openai.azure.com/openai/deployments/your-deployment) as the customOpenAIEndpoint and using an Azure API key. Ensure your deployment supports the chat completions format.

Is the custom endpoint hard-coded in the application?

No. According to the Meetily source code, the endpoint is supplied at runtime to the generate_summary function. You can change the target URL for every summary request without recompiling the application, or persist it in the settings store for consistency across sessions.

What authentication method does Meetily use with custom endpoints?

Meetily passes the apiKey parameter as the Authorization: Bearer header in the HTTP request constructed by llm_client.rs. This standard Bearer token authentication works with OpenAI, Azure, and most proxy services. If your custom endpoint requires different authentication, you must modify the request construction in llm_client.rs.

Can I use Ollama instead of a custom OpenAI endpoint?

Yes, but through a different code path. Meetily has a separate Ollama provider variant that uses the ollama_endpoint parameter instead of custom_openai_endpoint. If you want to use Ollama with OpenAI compatibility (such as Ollama's OpenAI-compatible API mode), you would treat it as a custom-openai provider and point the endpoint to your local Ollama instance with the appropriate path.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}