OpenAI-compatible endpoints
Point Memtro at another server that speaks the OpenAI chat format: approving its host for your organisation, adding the endpoint, and what is refused.
The OpenAI-compatible endpoint is for a model server Memtro has no provider of its own for: a hosted inference service, such as Groq or Together AI, that answers the OpenAI chat-completions format under a base URL. You give it a label, the base URL and a key, and its models are addressed as compat:<label>/<model>.
Whatever answers at the endpoint receives the conversation, the memory retrieved for it, tool results and the endpoint's key. So on hosted Memtro it takes two steps: an owner or admin approves the endpoint's host for the organisation, and then anyone allowed to add a model key adds the endpoint.
Approve the host (owner or admin)
On Organisation → Providers, under Custom model hosts:
- In Approve a host, type the host name, such as
api.groq.com, or paste the endpoint's URL and its host is taken. - Press Approve. Memtro checks the name, and looks it up to make sure it is on the public internet, before adding it. The answer reads
<host> is approved. Anyone here with permission to add a key can now point an OpenAI-compatible endpoint at it.
Approve exact host names. An approval covers that name only: a subdomain or a look-alike of an approved host is not covered. An organisation can approve up to 20 hosts. These cannot be approved:
- an IP address, a wildcard, or a name with no dot in it;
- a local or reserved name, such as
localhostor anything under.localor.internal; - a name on
memtro.com, which is Memtro's own; api.openai.com,api.anthropic.comandgenerativelanguage.googleapis.com, which every organisation may use already;- a name that does not resolve, or that resolves to a private or internal address.
Only an owner or admin can approve or withdraw a host.
Each approved host shows how many keys point at it. To withdraw one, press remove beside it. Keys that point at it are not deleted, but they are refused from the next request, within about a minute, until the host is approved again or the key is replaced. The answer says how many keys that is, members' own keys included.
Approvals and withdrawals are recorded in the audit log, and so is every OpenAI-compatible key a member adds or removes for themselves, with its host.
Add the endpoint
On Dashboard → Providers pick OpenAI-compatible endpoint and fill in:
| Field | What goes in it |
|---|---|
| Label | The name in the model id, compat:<label>/<model>. It is lower-cased, and any character other than a–z, 0–9, _ and - becomes -. Required. |
| Base URL | The address the server's OpenAI routes sit under, including the version path, e.g. https://api.groq.com/openai/v1. It must be https:// on an approved host, on port 443 or a port from 1024 to 65535, with no user name or password in it. Memtro adds /models and /chat/completions to it exactly as given. Required. |
| API key | The endpoint's API key, sent as a bearer token. Required. |
Then choose who it is for: Personal (only you), Shared with your organisation, or one team. Which of these you are offered depends on your permissions. Work done for the organisation or a team, such as its jobs and its connections' syncs, spends only shared and team keys, never a member's personal one; your own personal jobs and personal connections can use your personal key.
Saving checks the base URL first. If its host is not approved, not on the public internet or not reached over HTTPS, nothing is saved and the form says why (see Refusals). A member is told that an administrator can approve the host under Organisation → Providers; an owner or admin is told to approve it under Custom model hosts and then add the key again.
Saving does not send a test request. Memtro stores the key encrypted, never shows it again, and asks the server for its models. A good key comes back as Added openai_compatible key (personal). with the number of models found after it. If the listing fails, the key is still saved and the form says Saved. Listing models failed: <reason>. Check the key, then use Refresh models. The reason is usually compat and the HTTP status the server answered with, such as compat 401 for a key it refused. Refresh models beside the key asks again; a server that answers with an empty list reads This provider does not list its models; the built-in ids still work., and model ids you name still go through.
Several keys can share one label. They then stand for the same endpoint, ordered like any provider's keys: see several keys for one provider.
Refusals
The base URL is checked when a key is saved, when its models are listed, and again on every request. On the Providers page a refusal reads as below, with the host and your organisation's name filled in. Over the API it is an HTTP 400 of type invalid_request_error with the code shown.
| On the Providers page | API code | What it means |
|---|---|---|
<host> is not an approved model host for <organisation>. and who can approve it | provider_base_url_not_allowed | The host is not on the organisation's Custom model hosts, or has been withdrawn. An owner or admin approves it. |
<host> is a private or internal address. A model endpoint has to be on the public internet. | provider_base_url_not_allowed | The host, or an address it resolves to, is on a private network, loopback, or Memtro's own infrastructure. |
<host> does not resolve. Check the host name in the base URL. | provider_base_url_not_allowed | DNS has no answer for the name. |
<host> answered with a redirect, which Memtro does not follow for a model endpoint. Use the address it redirects to as the base URL. | provider_base_url_not_allowed | The server answered with a redirect. Following it would send the conversation and the key to a host nobody approved. |
Model endpoints are reached over HTTPS only. Use an https:// base URL. | invalid_provider_base_url | The base URL is http:// or another scheme. |
That port is not accepted. Use the default HTTPS port (443) or a port from 1024 to 65535. | invalid_provider_base_url | The base URL names a port below 1024 other than 443. |
Put the key in the API key field, not in the base URL: a URL with a user name or password in it is not accepted. | invalid_provider_base_url | The base URL carries a user name or password. |
The base URL must be an absolute https:// URL, like https://api.groq.com/openai/v1. | invalid_provider_base_url | The base URL cannot be read as a URL. |
Base URL is required for OpenAI-compatible endpoints. | provider_not_configured | There is no base URL. |
These codes are returned on chat completions, Responses and embeddings, whether the endpoint is refused before the request is sent or during it. Messages answers in Anthropic's error shape, with the type invalid_request_error and no code; the message says why. A refusal after a stream has started arrives as that stream's error event, like any other failure mid-stream. See the error catalogue.
What an endpoint must be
- On the public internet, over HTTPS. Hosted Memtro cannot reach a server on your own machine or private network,
localhostincluded, and an approval does not change that. Every address a host name resolves to is checked, and one private address among public ones refuses the host. - Checked on every request. Each request checks the host against the organisation's list and looks it up again, and the address Memtro actually connects to is judged too, so a host whose DNS later points somewhere private is refused at use, not only when the key was saved.
- No redirects. A redirect is refused rather than followed; use the address it points to as the base URL.
- An exact host. Up to 20 per organisation. A withdrawn host's keys are refused within about a minute.
Other providers never use the organisation's list. On the Anthropic, OpenAI and Google providers, hosted Memtro accepts a base URL override only on Anthropic's, OpenAI's or Google's own API host. The built-in providers that speak the OpenAI format, Meta, xAI, OpenRouter and DeepSeek, are called at their fixed addresses, and the Claude Code and Codex engines are held to the same rule as Anthropic and OpenAI.
Model ids
| Id | What it is |
|---|---|
compat:<label>/<model> | <model> is the server's own id, sent as written. It may contain slashes: everything after the first slash belongs to it. |
There is no default ladder for an endpoint and no auto/compat id. To route to its models, an administrator chooses them per level on the Routing page. A named model is used only where model choice has been opened there; otherwise it is answered as memtro (see cost control).
What is different about an endpoint in Memtro
- Chat completions only. Memtro speaks the OpenAI chat-completions format to the endpoint, with no extra headers. What the server supports beyond that is up to the server.
- No reasoning setting. Memtro passes no thinking or effort setting: a
reasoning_efforton the request, and agent mode's request for deeper thinking, have no effect here. - Usage in tokens. Each request is recorded with the tokens the server reports. Allowances are set in tokens, and Memtro does not price them.
Example servers
These show the base URL shape each project documents, as of November 2026. They are examples, not recommendations.
| Server | Base URL its docs give | Host to approve and notes |
|---|---|---|
| Groq | https://api.groq.com/openai/v1 | api.groq.com. The path is /openai/v1, not /v1. Keys at console.groq.com/keys. |
| Together AI | https://api.together.ai/v1 | api.together.ai. A US-only address, https://us-api.together.ai/v1, is also given; it is another host and needs its own approval. |
| Ollama | https://ollama.com/v1 for its cloud, with an Ollama API key | ollama.com. A local Ollama answers at http://localhost:11434/v1/, which is not reachable from hosted Memtro (below). |
| vLLM | Your server's address followed by /v1 | vLLM serves /v1/models and /v1/chat/completions on the host you run it on (below). |
A server you run yourself, such as Ollama or vLLM on your own machine or private network, cannot be reached from hosted Memtro, because Memtro calls only https:// hosts on the public internet. To use one, serve it at a public https:// address under a host name of its own that resolves only to public addresses, and approve that host.
Your data at an endpoint
What happens to a request depends entirely on whoever runs the server: read its own terms on training and retention. A request through Memtro usually carries your organisation's memory with it. See privacy for what erasure in Memtro cannot reach.
Limits
- The host has to be approved by an owner or admin, by its exact name, up to 20 per organisation.
- The endpoint has to be on the public internet over HTTPS. A private network or
localhostcannot be reached from hosted Memtro, and redirects are not followed. - A withdrawn host's keys are refused within about a minute.
- An endpoint has no default ladder and no
auto/id. - An endpoint's key does not embed your organisation's memories on hosted Memtro; memory uses an OpenAI or Google key your organisation holds, or Memtro's own embedding model.