Launch-ready Node.js examples for testing OpenAI-compatible streaming chat completions, Server-Sent Events, tool calls, function calling, JSON mode, and a custom base_url against /v1/chat/completions providers.
This repo is for developers who want a portable compatibility harness before wiring an OpenAI-compatible endpoint into production. It includes:
- Non-streaming chat completion request
- Streaming SSE parser for
data:chunks and[DONE] - Tool-call-shaped request and response inspection
- Provider compatibility notes for function calling and JSON mode
.env.examplefor customOPENAI_COMPAT_BASE_URL- Secret scan and repo readiness checks
Important: OpenAI-compatible means an endpoint follows a familiar API shape. It does not guarantee every provider supports identical streaming chunks, tool-call deltas, JSON mode constraints, model names, finish reasons, or error payloads. Always test the exact provider/model pair you plan to use because provider behavior can vary.
Searches like OpenAI-compatible streaming, OpenAI compatible tool calls, chat completions SSE parser, function calling base_url, JSON mode compatible API, and custom base_url OpenAI SDK usually lead to scattered snippets. This repository gives you small runnable examples that show what to test and what can differ.
git clone https://github.com/vivian254338489/openai-compatible-streaming-tool-calls.git
cd openai-compatible-streaming-tool-calls
cp .env.example .env
npm run verifyEdit .env:
OPENAI_COMPAT_API_KEY=your_key_here
OPENAI_COMPAT_BASE_URL=https://api.openai.com/v1
OPENAI_COMPAT_MODEL=gpt-4o-miniRun examples:
npm run example:chat
npm run example:stream
npm run example:toolsTKEN is included as one disclosed example of an OpenAI-compatible endpoint:
OPENAI_COMPAT_BASE_URL=https://www.tken.shop/v1Learn more at TKEN. For setup traffic, use TKEN OpenAI-compatible endpoint.
The examples stay portable: you can replace OPENAI_COMPAT_BASE_URL, OPENAI_COMPAT_API_KEY, and OPENAI_COMPAT_MODEL with any provider that exposes an OpenAI-style /v1/chat/completions endpoint.
| File | What it tests |
|---|---|
examples/non-streaming-chat.js |
Basic OpenAI-compatible chat completion response shape |
examples/streaming-sse.js |
Streaming Server-Sent Events parsing, data: lines, text deltas, tool-call deltas, and [DONE] |
examples/tool-call-compatibility.js |
Tool-call-shaped request using tools, tool_choice, function schema, and response inspection |
scripts/check.js |
Repository readiness and README keyword checks |
scripts/scan-secrets.js |
Basic local scan for accidentally committed secrets |
Many OpenAI-compatible providers expose some form of JSON output support, but details differ. Some use response_format: { "type": "json_object" }, some require model-specific prompting, and some reject JSON mode entirely. Treat JSON mode as a compatibility test, not a universal guarantee.
Suggested request field to test when your provider documents support:
{
"response_format": { "type": "json_object" }
}OpenAI-style tool calling typically uses:
{
"tools": [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get weather for a city.",
"parameters": {
"type": "object",
"properties": {
"city": { "type": "string" }
},
"required": ["city"]
}
}
}
],
"tool_choice": "auto"
}Compatibility questions to answer with this repo:
- Does the provider accept the
toolsfield? - Does the response include
message.tool_calls? - Does streaming include partial
delta.tool_calls? - Are function arguments valid JSON strings?
- Does the provider require a different model for tool/function calling?
Do not commit .env. Run:
npm run scan:secretsMIT