All posts
Engineering

OpenAI-Compatible API: What 'Compatible' Actually Means

Prototype content preview. Figures, author details, product claims and API examples are pending verification; examples are not confirmed integration instructions.

We walk through every endpoint, parameter, and edge case in our OpenAI compatibility layer — including where we intentionally diverge.

Plenty of gateways claim OpenAI compatibility and then quietly drop the half of the surface area you depend on. Here is exactly what we implement, what we extend, and where we deliberately diverge.

Fully supported

  • /v1/chat/completions including streaming, tools, tool_choice, and structured outputs
  • /v1/embeddings with batching
  • /v1/images/generations and edits
  • /v1/audio/transcriptions, translations, and speech
  • /v1/models with provider-qualified IDs

The one-line switch

from openai import OpenAI

client = OpenAI(
    base_url="https://api.starsg.ai/v1",
    api_key=STARSG_API_KEY,
)

Where we diverge

Three deliberate differences. First, model IDs are provider-qualified so the same name never means two things. Second, rate-limit headers report your pooled gateway limit, not the upstream vendor's. Third, we return an extra amplink block on every response carrying the model actually served, cache status, and whether a failover occurred.

Anything that would silently change the meaning of a field, we do not do. Extensions go in extra_body on the way in and a namespaced block on the way out.

Unsupported parameters are rejected with a 400 rather than ignored. Silently dropping logit_bias is how you end up debugging a quality regression for a week.

More in Engineering

How to Get Gemini 4 Argon API-Ready

Oct 15, 2026 · 19 min read

Jev Explained: How to Build Reliable, Typed AI Decisions for Production

Oct 10, 2026 · 20 min read

What Is an LLM API? A Practical Guide for Developers

Sep 16, 2026 · 11 min read