A buyer’s guide to OpenAI‑compatible APIs

“OpenAI-compatible” describes a specific API surface. It does not guarantee full parity with every OpenAI endpoint, model name, request field, response field, or SDK feature. Before you migrate, confirm the exact interface the provider documents and test it with your own workload.

Hivenet offers two OpenAI-compatible paths with different operating models. Hivenet Inference API provides managed, dedicated model endpoints. Compute with Hivenet provides GPU or CPU infrastructure where you install and operate vLLM or another serving stack yourself.

Choose the right Hivenet path

• Use Hivenet Inference API when you want Hivenet to operate the serving layer, gateway, runtime, replicas, and endpoint infrastructure. You choose from the managed catalog and the locations currently available in the console.
• Use Compute with Hivenet when you need custom weights, a different inference runtime, operating-system access, or full control over authentication, networking, updates, and monitoring.

Do not use the feature list for one path as proof of what the other path supports. A self-managed vLLM server exposes the features of the version and configuration you deploy. The managed Inference API exposes the interface described in the current Hivenet documentation and console-generated examples.

What to verify before you switch

1. Documented routes

Ask for the exact supported endpoints instead of relying on the phrase “OpenAI-compatible.” Hivenet’s current managed Inference API documentation covers Chat Completions. Do not assume that legacy completions, embeddings, model listing, moderation, or another OpenAI route is available unless the current documentation or the endpoint’s generated example says so.

2. Base URL and authentication

Confirm whether the supplied endpoint URL already contains /v1. Hivenet Inference API endpoint URLs do, so use the URL copied from the console without appending a second /v1. Create the API key in the active organization, store it outside source code, and use it only with endpoints owned by that organization.

3. Exact model value

Use the model value from the endpoint’s quick-start example. It can differ from the endpoint name or the model family shown in the catalog. Keep the endpoint URL, API key, and model value in configuration so you can change providers or deployments without rewriting application logic.

4. Requests and responses

Start with a small non-streaming Chat Completions request. Verify the status code and the fields your application reads. Then test optional behavior such as streaming, tool calling, structured output, stop sequences, or token-usage fields only when the provider documents it for the endpoint you are evaluating.

5. Errors and retries

Record the status code and response body that the service actually returns. Do not build against an example error schema or rate-limit header that the provider has not documented. Retry temporary failures with bounded exponential backoff, honor Retry-After when it is present, and avoid retrying authentication or validation failures without correcting the request.

6. Quality, latency, and cost

Build a representative prompt set from your real workload. Compare answer quality, time to first token where available, total latency, throughput, and cost under the same request pattern. Test the model and replica configuration you intend to use, not a nearby model name or a marketing benchmark.

7. Location and data handling

Choose from the locations currently available for the endpoint and confirm that the selected location and contractual terms meet your requirements. Do not infer logging, retention, residency, or compliance guarantees from the region name alone.

Connect to a managed Hivenet endpoint

Create an endpoint in the Hivenet Compute console, wait until it is running, create an Inference API key, and copy the generated quick-start values. The endpoint URL already includes /v1.

Python

import os
from openai import OpenAI

client = OpenAI(
  base_url=os.environ["HIVENET_ENDPOINT_URL"],
  api_key=os.environ["HIVENET_INFERENCE_API_KEY"],
)

response = client.chat.completions.create(
  model=os.environ["HIVENET_MODEL"],
  messages=[
    {"role": "user", "content": "Write a one-sentence status update."}
  ],
)

print(response.choices[0].message.content)

JavaScript

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.HIVENET_ENDPOINT_URL,
  apiKey: process.env.HIVENET_INFERENCE_API_KEY,
});

const response = await client.chat.completions.create({
  model: process.env.HIVENET_MODEL,
  messages: [
    { role: "user", content: "Give me one key risk for this project." },
  ],
});

console.log(response.choices[0].message.content);

Use the exact endpoint URL and model value shown by your endpoint. If the first request fails, follow the Inference API troubleshooting guide before changing client behavior.

Run your own OpenAI-compatible server on Compute

Choose Compute when you want to deploy vLLM, TGI, SGLang, llama.cpp, or another runtime yourself. In this path, you are responsible for the runtime version, supported routes, model files, authentication, connectivity, updates, scaling, and monitoring.

Start with the Compute quickstart and the current Compute FAQ. After the server is running, test the interface documented by that runtime and configuration. A route supported by one vLLM release or template should not be assumed to exist on every self-managed deployment.

A practical migration checklist

1. Choose managed Inference API or self-managed Compute.
2. Copy the exact endpoint URL and model value from the current source.
3. Send one non-streaming Chat Completions request.
4. Test only the optional routes and fields the provider documents.
5. Compare quality, latency, throughput, and cost with representative prompts.
6. Verify error handling without assuming a particular schema or header.
7. Confirm location, data-handling, and contractual requirements before production use.
8. Keep provider-specific values in configuration and retain a rollback path.

Frequently asked questions

Does OpenAI-compatible mean every OpenAI endpoint works?

No. Compatibility is normally limited to the routes and fields a provider documents. Test the exact interface you need.

Which Hivenet product should I use?

Use Hivenet Inference API for a managed, dedicated endpoint. Use Compute with Hivenet when you want to operate the serving stack and control the runtime yourself.

Can I reuse the same model name I use with OpenAI?

Do not assume so. Use the exact model value shown in the endpoint’s generated example and keep it in configuration.

Should I append /v1 to a Hivenet Inference API URL?

No. The endpoint URL copied from the Hivenet console already includes /v1.

Where should I check current models and locations?

Use the live Hivenet console and the models and variants documentation. Availability can change by model, variant, capacity, and location.

When you are ready, open the Hivenet Compute console and choose the managed or self-managed path that fits your workload.