Configure LibreChat to use CometAPI through an environment-backed custom endpoint.

Last reviewed: 2026-08-29

Direct answer

Configure CometAPI under endpoints.custom in librechat.yaml, reference the API key through a short environment-variable name, and use CometAPI’s documented OpenAI-compatible /v1 API root. For Docker, mount the YAML file into the LibreChat API container and restart the deployment. Select a current text-capable model explicitly, choose the CometAPI endpoint in LibreChat, and send a small verification prompt.

This arrangement follows the three-file boundary in the LibreChat custom-endpoint guide : librechat.yaml defines the endpoint, .env holds the sensitive value, and docker-compose.override.yml mounts the configuration. It also matches the CometAPI OpenAI-compatible quickstart , which identifies the /v1 root and Chat Completions request path for compatible clients.

Do not set provider: anthropic merely because the selected CometAPI model comes from the Claude family. LibreChat reserves that setting for gateways speaking the native Anthropic Messages protocol. CometAPI in this tutorial is being used through its OpenAI-compatible path, so the provider field stays omitted.

Who this is for

This guide is for developers and self-hosters who already have LibreChat running and can edit its deployment files. It is especially useful when one administrator manages the CometAPI connection for the deployment and does not want the key committed in YAML or source control.

The workflow targets the configuration-file path, not a user-by-user settings form. CometAPI also publishes a shorter LibreChat settings walkthrough , but its UI flow and base-URL handling should not be copied mechanically into a custom YAML entry. LibreChat’s custom endpoint client appends the completion route unless directEndpoint is enabled, so the API root matters.

Key takeaways

• Keep the sensitive value in .env; let librechat.yaml reference its variable name.
• Use a unique endpoint name such as CometAPI, and omit provider for the OpenAI-compatible route.
• Put the /v1 API root in COMETAPI_BASE_URL, not the full Chat Completions URL.
• Choose a current text-capable model from the public catalog and list it under models.default.
• Start with models.fetch: false so the first test does not depend on automatic model discovery.
• Set titleModel: 'current_model' to avoid LibreChat’s documented fallback to a model that might not be available.
• Treat endpoint visibility and a successful reply as separate checks: the first proves configuration loading; the second proves the request path.

Sources checked

• LibreChat Custom Endpoints documents the YAML, environment, Docker mount, restart, and endpoint-selector workflow.
• LibreChat Custom Endpoint Object Structure defines apiKey, baseURL, models.default, models.fetch, titleModel, dropParams, and native-provider behavior.
• CometAPI OpenAI-compatible API quickstart documents the /v1 root, model requirement, and Chat Completions flow.
• CometAPI’s LibreChat integration guide confirms that a successful conversation is the end-to-end connection check.
• CometAPI’s public model catalog reference explains how to inspect model IDs, providers, capabilities, and endpoint hints without an authenticated catalog request.

Contract details to verify

Start by choosing a model. The public catalog contains several media types, so do not copy the first ID returned and assume it supports chat. Inspect the model’s type, features, and endpoint hints, then copy the exact ID for a text-capable model. This tutorial uses a placeholder because catalog entries can change independently of LibreChat.

Put the sensitive value and API root in .env. Copy the exact /v1 root from the linked CometAPI quickstart when replacing the second placeholder.

COMET_KEY=[REDACTED]
COMETAPI_BASE_URL=[DOCUMENTED_API_ROOT]

Create or update librechat.yaml in the project root:

version: 1.3.13
cache: true
endpoints:
  custom:
    - name: 'CometAPI'
      apiKey: '${COMET_KEY}'
      baseURL: '${COMETAPI_BASE_URL}'
      models:
        default:
          - '[CURRENT_TEXT_MODEL_ID]'
        fetch: false
      titleConvo: true
      titleModel: 'current_model'
      modelDisplayLabel: 'CometAPI'

Replace [CURRENT_TEXT_MODEL_ID] before restarting. Keep provider omitted. Also leave directEndpoint at its default because baseURL is an API root rather than a full completion endpoint. The LibreChat object reference says the application appends its completion path by default; directEndpoint is for a base value that already names the full completion endpoint.

For Docker, ensure docker-compose.override.yml mounts the file:

services:
  api:
    volumes:
      - type: bind
        source: ./librechat.yaml
        target: /app/librechat.yaml

Then follow a concrete happy-path workflow:

1. Confirm that .env, librechat.yaml, and the Docker override are in the deployment directory.
2. Confirm that the environment variable names match exactly and that the YAML contains a current text-capable model ID.
3. Restart LibreChat as documented by its custom-endpoint guide.

docker compose down && docker compose up -d

4. Open LibreChat and verify that CometAPI appears in the endpoint selector.
5. Select the configured model and send: Reply with exactly connection-ok.
6. Confirm that LibreChat displays a successful assistant reply. This proves more than endpoint visibility: it shows that the runtime loaded the environment value, reached the configured API family, accepted the model ID, and returned a chat response.

Keep a sanitized operator record for both success and failure. A compact record can look like this:

{
  "timestamp": "2026-08-29T00:00:00Z",
  "component": "librechat-api",
  "config_version": "1.3.13",
  "endpoint_name": "CometAPI",
  "api_root_host": "api.cometapi.com",
  "api_root_path": "/v1",
  "model_id": "[CURRENT_TEXT_MODEL_ID]",
  "http_status": 200,
  "elapsed_ms": 0,
  "outcome": "success",
  "request_id": "[IF_RETURNED]"
}

Record the timestamp, component, endpoint name, API host and path, selected model, status, elapsed time, outcome, and a server request identifier only when one is returned. For an error, add a short error type and a truncated, sanitized message. Do not record the environment value, request headers, complete prompt history, or full response content. A boolean such as env_reference_present can show that configuration was detected without exposing its value.

For the error path, work outward from configuration loading:

1. If CometAPI is absent from the selector, inspect docker compose logs api for YAML parsing, missing-variable, or mount errors. Correct the file chain and restart before testing the network path.
2. If the endpoint appears but the request returns 401, verify that COMET_KEY is populated in the environment used by the LibreChat API process. Do not repeatedly retry an authentication failure.
3. If the model is rejected, check the public catalog again and compare the exact model ID and endpoint hints with the YAML value.
4. If the route returns 404, check that COMETAPI_BASE_URL names the documented /v1 root rather than the site root or a duplicated full completion route.
5. If the selected route returns 422, capture the sanitized error before changing parameters. LibreChat supports dropParams, but remove fields only when the selected model’s documented contract or the returned error identifies them.
6. Retest with the same small prompt after one correction. Changing the root, model, and parameters simultaneously makes the result hard to interpret.

For a separate preflight on endpoint construction, see how to verify a client base URL .

Failure modes

Avoid blind retries for configuration, authentication, model, and route errors. These failures are deterministic until an operator changes the relevant input. A retry is useful only after that correction.

FAQ

Should the CometAPI key be written directly in librechat.yaml?

No. LibreChat recommends an environment-variable reference for YAML-defined endpoints. This keeps the sensitive value out of the configuration file while still allowing the API process to load it at runtime. If the repository contains deployment examples, also follow the guidance on keeping CometAPI keys out of tutorial repositories .

Should I set provider: anthropic for a Claude-family model?

Not in this OpenAI-compatible configuration. LibreChat uses provider: anthropic to route through the native Anthropic Messages client. A gateway exposing a Claude-family model through an OpenAI-compatible Chat Completions route should keep provider omitted.

Why does this guide use models.fetch: false?

LibreChat can attempt model discovery when fetch is true, but its documentation warns that discovery can delay initial use. CometAPI separately documents a public catalog endpoint. Selecting an explicit, current text model makes the first test independent of whether LibreChat’s automatic discovery request matches that catalog contract.

Which base URL belongs in the custom YAML endpoint?

Use the /v1 API root documented for OpenAI-compatible clients, supplied through COMETAPI_BASE_URL. Do not use the full Chat Completions endpoint unless you deliberately enable and verify directEndpoint. Do not assume that a URL shown in a settings-screen walkthrough has the same path-building behavior as a YAML custom endpoint.

How do I know the integration is actually working?

First confirm that the endpoint appears after restart. Then select it and send a small prompt. A successful reply is the end-to-end check described by CometAPI’s LibreChat guide. Preserve only the sanitized operational fields needed to reproduce the test.

What should I change first when a request fails?

Change the narrowest input indicated by the symptom: mount or syntax for a missing endpoint, environment delivery for 401, model ID for model errors, API root for 404, and request parameters for a documented 422. Retest after each single change.

Reader next step

Choose one current text-capable model from the public catalog, place the redacted configuration template into your LibreChat deployment, mount it, restart, and run the one-line verification prompt. Save the sanitized outcome so a later model or configuration change can be compared against a known working path.

When you are ready to create the account and environment-backed connection, Start with CometAPI .