Compatibility describes an interface, not every behavior
- The official OpenAI reference documents POST /chat/completions as accepting conversation messages and returning a chat completion with choices. It also defines finish reasons such as stop, length, content_filter, and tool_calls. Those fields give you a concrete baseline for a compatibility test.
- A third-party endpoint may accept the same path and core fields without matching every parameter, event, error, model capability, or operational rule. Treat the label OpenAI-compatible as a hypothesis to test against your application's contract, not proof of an interchangeable service.
Test the paths your application actually uses
- Start with authentication rejection and model discovery, then send a minimal non-streaming completion. Validate the status code, content location, model value, usage fields you consume, and finish reason. Repeat with streaming only if your application uses it, checking event termination and partial-content handling.
- Next test the features that would break a migration: system instructions, tool calls, JSON or structured output, image input, stop behavior, token limits, and cancellation. FreeToken.link's Models area can identify candidates, while its Playground provides a bounded place to test the request before changing production code.
Errors and limits are part of compatibility
- Run negative cases with a missing credential, an invalid model, malformed input, and an intentionally constrained request. Your adapter needs predictable status codes and parseable errors; a success-only demo does not show whether retries, fallbacks, or user-facing messages will behave correctly.
- Operational rules can differ even when JSON looks familiar. Groq documents multiple organization-level limit dimensions, HTTP 429 responses, and rate-limit headers. A compatibility review should capture the provider's current limit scope and retry signals rather than inherit assumptions from another API.
Separate pass, adapter required, and unsupported
- For each capability, record one of three outcomes: passes unchanged, works through an adapter, or is unsupported. Include the request fixture and a redacted response sample so the result can be rerun when the provider, SDK, or model changes.
- Only call an endpoint drop-in compatible if every behavior required by the application passes without adaptation. Otherwise, describe the narrower truth—for example, chat-completion compatible for non-streaming text—and put the route on the FreeToken.link Watchlist for future verification.
Frequently asked questions
Is an OpenAI-compatible API the same as the OpenAI API?
No. It may implement a similar interface, but that alone does not establish identical features, responses, limits, or service behavior.
What is the smallest useful compatibility test?
Verify auth rejection, model discovery, one minimal completion, the response fields you consume, and at least one failure case.
When is an adapter acceptable?
When the difference is explicit, tested, and isolated. Document the adapter instead of presenting the underlying endpoint as fully drop-in compatible.
AI assistance is disclosed; every factual claim was reviewed.
The first draft was produced through the locally hosted basketikun/chatgpt2api wrapper from a fixed pack of official-source facts. That wrapper uses a ChatGPT web-session route and is not the official OpenAI API. A human editor checked every retained claim against the linked references and added the success, failure, and feature-test matrix before publication.