SideNote ProConfigure any OpenAI-compatible provider
The four presets are conveniences, not a whitelist. Any service implementing the OpenAI-compatible Chat Completions API can be configured by hand. This explains exactly what SideNote Pro expects, so you can tell in advance whether a service will work.
The contract SideNote Pro expects
- Bearer-token authentication when an API key is present, and no auth header when the key field is empty.
- `GET {BaseUrl}/models` for connection testing and optional model discovery.
- Streaming `POST {BaseUrl}/chat/completions` for generation.
- Server-Sent Events using
data:records, terminated by[DONE]. - A `choices` array containing
delta.content,message.contentortext.
The stream parser deliberately tolerates the several string, object and content-array variations that compatible providers return in practice, so minor shape differences generally do not matter. Usage metadata is optional: common prompt, input, completion, output and total token fields are recognised where present, and endpoints that omit usage entirely are fully supported.
Configuring the profile
- Find the base URL in the provider's documentationLook for the value their OpenAI SDK examples set as the base URL. It usually ends in
/v1. That exact string is what goes in the Base URL field. - Add the API key if the service requires oneLeave it empty for services that do not authenticate, such as a local server on your own machine.
- Set the model IDRun the connection test first. If
GET /modelsworks, choose from the discovered list. If it does not, type the model ID exactly as the provider documents it. Model IDs are usually case-sensitive and often carry a vendor prefix. - Leave reasoning effort on Provider defaultChange it only if the provider documents
reasoning_effortsupport for that model.
The single most common mistake is the base URL. Too much (/chat/completions appended) and every request 404s. Too little (no /v1) and the same. Copy what the provider's own OpenAI-SDK example uses, and nothing more.
Where compatibility usually breaks
*OpenAI-compatible* describes a request format. It does not promise that every optional field and every model capability behaves identically. These are the differences that actually come up.
| Gap | What you see | What to do |
|---|---|---|
No /models route | Connection test fails but sending works | Type the model ID manually; discovery is optional |
reasoning_effort unsupported | The value is ignored, or the request is rejected | Set reasoning effort back to Provider default |
| No image input | Images ignored, or an error mentioning content type | Use a vision-capable model, or send text only |
| No usage metadata | Token figures shown as local estimates | Nothing. Estimates are used automatically |
| Non-standard streaming | Empty or truncated responses | Check the provider streams SSE with [DONE] |
| Different model naming | Model not found on send, though the key works | Copy the exact ID from the provider's documentation |
Features SideNote Pro does not use
Worth knowing when evaluating a provider, because none of these will make a difference to whether it works here: the OpenAI Responses API, tool and function calling, built-in web search, audio, video and image generation. SideNote Pro sends text and images over streaming Chat Completions and renders streamed text back.
So a provider advertising a rich agentic toolset is not more compatible than a plain one. What matters is whether streaming chat/completions is implemented properly.