[PR #1359] [CLOSED] docs: add Synthorai to the OpenAI-compatible cloud providers #1330

New issue

Closed

opened 2026-10-18 14:18:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:18:54 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/docs/pull/1359
Author: @cuihuan
Created: 8/27/2026
Status: ❌ Closed

Base: main ← Head: docs-add-synthorai

📝 Commits (1)

5943648 docs: add Synthorai to the OpenAI-compatible cloud providers

📊 Changes

1 file changed (+15 additions, -0 deletions)

View changed files

📝 docs/getting-started/quick-start/connect-a-provider/starting-with-openai-compatible.mdx (+15 -0)

📄 Description

Disclosure: I am affiliated with Synthorai — this adds our own product to the provider list, not demand I am relaying from elsewhere. Flagging it so the change is judged with that on the table. No expectation of priority, and "not now" is a fine answer.

This PR was prepared with an AI agent. Every factual claim below is backed by a command I ran; where something was not verified, that is said outright.

Why here

Synthorai speaks the OpenAI Chat Completions protocol, so it needs no core code — which is the case this page exists for. Per Protocol-Oriented Design, gateways belong here rather than in a provider-specific module, and OpenRouter and Vercel AI Gateway already have tabs.

What changed

One <TabItem> in starting-with-openai-compatible.mdx, inside ### Cloud Providers, placed between Vercel AI Gateway and OpenRouter so the gateway entries stay together. One file, 15 added lines, nothing removed or reordered.

Shape mirrors the Vercel AI Gateway tab: bold lead sentence, the three-row settings table, one :::tip.

The one claim I measured rather than assumed

The tab states /models auto-detection works, which this page documents for every provider. I tested it against a real key rather than inferring it:

GET /v1/models  + Bearer <key>   →  HTTP 200, 67 models, each with id/object/owned_by

Two things worth flagging, because they change what the tip should say:

/models returns what the key is permitted to use, not the full catalog. The key I tested returned 67 of the 113 models in our public catalog; the difference is that key's model permissions, not endpoint behaviour. So the tip tells readers to check key permissions rather than hand-adding IDs — hand-adding an ID the key cannot use produces a model that appears in the selector and then fails on send.
A 401 from this endpoint proves nothing about it. Our auth sits on the /v1 prefix, so an unrouted path answers 401 too:
```
/v1/models        (no auth) → 401
/v1/definitely-not-real     → 401
```
I mention it only because your warning box reasonably treats a 401 during connection verification as a signal. For this gateway it is not one, and the tab does not ask readers to interpret it.

The list is small enough that the allowlist-and-caching advice in the OpenRouter tab does not apply here, so it is not repeated.

Deliberately not done

No row added to the "Providers with known /models issues" table. That table's stated subject is known issues, and this endpoint has none. Happy to add a | Synthorai | Yes | Auto-detection works | row if you would rather the table stay exhaustive.
JS/other pages untouched.
No screenshots. Neighbouring tabs in this file carry none.

Note on the precedent I was following

The last external provider addition I found here is #1054 (sylviezhang37, merged 2026-02-12), which edited docs/getting-started/quick-start/starting-with-openai.mdx — two one-line lists. That file no longer exists; the docs were reorganised and providers moved to this page as tabs with settings tables. So I followed the current file's conventions rather than that diff's shape. Saying so in case the older pattern is what you expect.

Where to look

The tip wording. It carries the only non-obvious claim in the change, and if "permitted to use" reads oddly for this page's audience I will reword it.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/docs/pull/1359 **Author:** [@cuihuan](https://github.com/cuihuan) **Created:** 8/27/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `docs-add-synthorai` --- ### 📝 Commits (1) - [`5943648`](https://github.com/open-webui/docs/commit/59436485e641e4fecb97de1a657081b0e626c27e) docs: add Synthorai to the OpenAI-compatible cloud providers ### 📊 Changes **1 file changed** (+15 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `docs/getting-started/quick-start/connect-a-provider/starting-with-openai-compatible.mdx` (+15 -0) </details> ### 📄 Description **Disclosure: I am affiliated with Synthorai** — this adds our own product to the provider list, not demand I am relaying from elsewhere. Flagging it so the change is judged with that on the table. No expectation of priority, and "not now" is a fine answer. This PR was prepared with an AI agent. Every factual claim below is backed by a command I ran; where something was not verified, that is said outright. ## Why here Synthorai speaks the OpenAI Chat Completions protocol, so it needs no core code — which is the case this page exists for. Per **Protocol-Oriented Design**, gateways belong here rather than in a provider-specific module, and `OpenRouter` and `Vercel AI Gateway` already have tabs. ## What changed One `<TabItem>` in `starting-with-openai-compatible.mdx`, inside `### Cloud Providers`, placed between `Vercel AI Gateway` and `OpenRouter` so the gateway entries stay together. One file, 15 added lines, nothing removed or reordered. Shape mirrors the `Vercel AI Gateway` tab: bold lead sentence, the three-row settings table, one `:::tip`. ## The one claim I measured rather than assumed The tab states `/models` auto-detection works, which this page documents for every provider. I tested it against a real key rather than inferring it: ``` GET /v1/models + Bearer <key> → HTTP 200, 67 models, each with id/object/owned_by ``` **Two things worth flagging, because they change what the tip should say:** 1. **`/models` returns what the key is permitted to use, not the full catalog.** The key I tested returned 67 of the 113 models in our public catalog; the difference is that key's model permissions, not endpoint behaviour. So the tip tells readers to check key permissions rather than hand-adding IDs — hand-adding an ID the key cannot use produces a model that appears in the selector and then fails on send. 2. **A 401 from this endpoint proves nothing about it.** Our auth sits on the `/v1` prefix, so an unrouted path answers 401 too: ``` /v1/models (no auth) → 401 /v1/definitely-not-real → 401 ``` I mention it only because your warning box reasonably treats a 401 during connection verification as a signal. For this gateway it is not one, and the tab does not ask readers to interpret it. The list is small enough that the allowlist-and-caching advice in the OpenRouter tab does not apply here, so it is not repeated. ## Deliberately not done - **No row added to the "Providers with known `/models` issues" table.** That table's stated subject is known issues, and this endpoint has none. Happy to add a `| Synthorai | Yes | Auto-detection works |` row if you would rather the table stay exhaustive. - **JS/other pages untouched.** - **No screenshots.** Neighbouring tabs in this file carry none. ## Note on the precedent I was following The last external provider addition I found here is #1054 (`sylviezhang37`, merged 2026-02-12), which edited `docs/getting-started/quick-start/starting-with-openai.mdx` — two one-line lists. **That file no longer exists**; the docs were reorganised and providers moved to this page as tabs with settings tables. So I followed the current file's conventions rather than that diff's shape. Saying so in case the older pattern is what you expect. ## Where to look The tip wording. It carries the only non-obvious claim in the change, and if "permitted to use" reads oddly for this page's audience I will reword it. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 14:18:54 +00:00