# User Authentication Methods in Meetily: Local API Keys and Optional Bearer Tokens

> Discover Meetily's user authentication methods. Learn how Meetily uses local API keys and bearer tokens instead of traditional passwords or OAuth for secure external service calls.

- Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily)
- Tags: api-reference
- Published: 2026-07-27

---

**Meetily does not implement traditional user authentication such as passwords, OAuth, or user accounts; instead, it stores optional LLM provider API keys and a generic bearer token locally for external service calls.**

The open-source **Zackriya-Solutions/meetily** repository is built as a privacy-first, locally-run desktop application. Understanding the user authentication methods in Meetily requires examining its Rust-based Tauri backend, where all credential handling is designed to keep data on the user's machine without remote login flows.

## No Built-In User Login or Account System

Meetily never contacts an external authentication service for user login. All UI state is managed locally via React contexts and Tauri commands, with no credential validation flow in the core application logic. The `SidebarProvider` and `ConfigContext` contexts, along with standard Tauri commands, do not reference any username or password validation.

## LLM Provider API Key Authentication

Since Meetily generates AI summaries and transcripts, it integrates with multiple LLM providers. Because the app has no centralized account system, it authenticates to these services using per-provider API keys stored in a local settings database.

### Local Storage via the Settings Repository

API keys for providers such as **OpenAI**, **Anthropic**, **Groq**, and custom OpenAI-compatible endpoints are persisted in the local database through the `setting` repository. The `setting_repo.save_api_key(provider_name, api_key).await?` pattern stores credentials on disk without transmitting them to a Meetily backend.

You can see the storage implementation in [`frontend/src-tauri/src/database/repositories/setting.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/repositories/setting.rs) around line 75, where keys are written to the local store alongside other application preferences.

### Runtime Retrieval and Provider Usage

At runtime, the summary module and provider clients retrieve these keys from the settings repository. For example, [`frontend/src-tauri/src/summary/mod.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/mod.rs) at line 18 documents the optional API key pattern, while provider-specific files such as [`frontend/src-tauri/src/openai/openai.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/openai/openai.rs) (line 99), [`frontend/src-tauri/src/anthropic/anthropic.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/anthropic/anthropic.rs) (line 69), and [`frontend/src-tauri/src/groq/groq.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/groq/groq.rs) (line 67) read the stored key and attach it to outgoing HTTP requests.

This design means **Ollama** users do not need an API key at all, because the model runs entirely on the local machine.

```rust
// Example of storing an LLM API key (OpenAI) via the settings repository
let api_key = Some("sk‑…".to_string());
setting_repo.save_api_key(provider_name, api_key).await?;

```

## Optional Bearer Token for Custom Backends

In addition to provider keys, Meetily supports an optional generic authentication token for users who run a custom backend server. This token is not required for standard desktop usage, but it enables authenticated communication when a self-hosted endpoint expects authorization.

### Token Retrieval from the Tauri Store

The `get_auth_token` function in [`frontend/src-tauri/src/api/api.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/api/api.rs) at line 208 reads the token from Tauri’s encrypted store under the exact key `authToken`. The function signature is `async fn get_auth_token<R: Runtime>(app: &AppHandle<R>) -> Option<String>`, returning `None` when no token is configured.

```rust
// Retrieve an optional auth token from the encrypted Tauri store
async fn get_auth_token<R: Runtime>(app: &AppHandle<R>) -> Option<String> {
    let store = app.state::<Store>();
    match store.get("authToken") {
        Ok(Some(token)) => {
            // Truncate for log safety
            let truncated = if token.len() > 6 {
                format!("{}***", &token[..6])
            } else {
                token.clone()
            };
            log_info!("Found auth token: {}", truncated);
            Some(token)
        }
        _ => {
            log_warn!("No auth token found in store");
            None
        }
    }
}

```

### Attaching the Token to Outgoing Requests

The `make_api_request` function in the same file (lines 260-267) conditionally adds the token as a `Bearer` header. If `auth_token` is `Some`, the request builder sets the authorization header before the HTTP call executes.

```rust
// Adding the token (if any) to a generic request
let mut request = reqwest::Client::new()
    .post(url)
    .json(&payload);

if let Some(token) = auth_token {
    log_info!("Adding authorization header");
    request = request.bearer_auth(token);
}

```

## Summary

- Meetily has **no built-in user login**, sign-up, OAuth, or password system according to the Zackriya-Solutions/meetily source code.
- **LLM provider API keys** are stored locally in the settings database and passed to client code at runtime.
- An **optional generic `authToken`** can be placed in Tauri’s encrypted store to enable `Bearer` authentication against custom backends.
- All credential handling is **local-only**, aligning with the application’s privacy-first architecture.

## Frequently Asked Questions

### Does Meetily require a user account to function?

No. Meetily is designed as a locally-run desktop application that never contacts an external authentication service for user login. All recordings, transcripts, and summaries are stored and processed on the user's machine without any remote account creation step.

### How are API keys stored in Meetily?

API keys are stored in the local settings database through the `setting` repository in [`frontend/src-tauri/src/database/repositories/setting.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/repositories/setting.rs). They are persisted on disk alongside other application preferences and are only retrieved when the app needs to call an external LLM provider.

### Can I use Meetily without sharing API keys with a remote server?

Yes. If you use **Ollama**, which runs entirely on your local machine, you do not need to provide an API key. The only time a key is required is when you choose to use cloud-based providers such as OpenAI, Anthropic, or Groq for summary generation.

### What is the optional auth token used for in Meetily?

The optional `authToken` is read from Tauri’s encrypted store and added as a `Bearer` header to outgoing HTTP requests through `make_api_request` in [`frontend/src-tauri/src/api/api.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/api/api.rs). It exists solely to support users who run a custom backend that expects bearer token authentication, and it is not used by default.