An OpenAI-Compatible API with Data Kept in Indonesia: Migrating Existing Code

An application that already calls OpenAI through Chat Completions can usually move to a model running in Indonesia by changing three things: the base URL, the API key, and the model name. IONext runs an OpenAI-compatible inference endpoint in Jakarta, so prompts and responses are processed onshore without rewriting the integration.

What does "OpenAI-compatible API" mean?

An OpenAI-compatible API accepts the same request format and returns the same response format as the OpenAI API. SDKs, libraries, and tools that already speak to OpenAI can be pointed at another provider without changing application logic. Only the destination address, the credentials, and the model answering the request change.

The Chat Completions format has become a de facto standard. The OpenAI SDK, LangChain, LlamaIndex, n8n, and many agent frameworks all expose a custom base URL option. That turns migration from "rewrite the integration" into "change the configuration, then test".

One thing needs to be clear from the start: compatible does not mean identical. The format is the same, but the model answering is different, and not every OpenAI endpoint is available from every provider. The section below details what IONext currently supports.

Why does this matter for projects with Indonesian client data?

Many system integrators and software houses build their first AI application on top of OpenAI. The problem shows up when the next client is a bank, a state-owned enterprise, a hospital, or a government agency that requires personal data to be processed inside Indonesia. Rewriting the integration for one client takes time and adds a codebase to maintain.

With an OpenAI-compatible API, a team can keep one codebase and pick the endpoint per client through configuration:

• Clients with no data-location requirement keep using whatever endpoint already works.
• Clients that require in-country processing get routed to the IONext endpoint in Jakarta.

For the second category of client, what usually comes up in review is processing location, the provider's legal entity, security certification, and billing currency. IONext is operated by PT Data Awan Nusantara in Jakarta, certified to ISO/IEC 27001:2022 by TÜV NORD, and bills in Rupiah. Certificate details and security controls are on the Security and Compliance page.

The regulatory context is covered in Using an LLM on customer data, what Indonesia's PDP Law requires and PP 33/2026: What It Means for AI Projects.

Which endpoints and features does IONext support?

As of 12 October 2026, the IONext inference endpoint supports Chat Completions and model listing, including streaming, function calling, structured output, and image input. Other OpenAI API endpoints, such as embeddings, are not available yet. The base URL is https://inference.ionext.ai/v1.

Component	Status
POST /v1/chat/completions	Supported
GET /v1/models	Supported
Streaming (stream=True)	Supported
Function calling / tools	Supported
JSON mode and structured output	Supported
Image input	Supported
/v1/completions (legacy)	Not available yet
/v1/embeddings	Not available yet

Models currently available:

Model name in the API	Notes
Qwen/Qwen3.8-27B-FP8	Dense 27B model from the Qwen team (Alibaba Cloud), FP8 quantized, 262K context extensible to 1M with YaRN, accepts text and image input

The model list can change. To see what is currently active, call GET /v1/models (an example is in step 4 below).

How to migrate existing code

For applications built on the OpenAI SDK, migration usually wraps up in five steps: get API access, store the API key as an environment variable, swap the base URL and model name, check the available models, then test with data from the actual use case.

1. Get API access

Create an account at the IONext console. Balance and API access activation are currently assisted by the IONext team, so after signing up, contact the IONext team for workspace activation.

2. Store the API key as an environment variable

Do not hardcode the API key. Store it in an environment variable or a secret manager:

export IONEXT_API_KEY="your-api-key-here"

3. Swap the base URL, API key, and model name

For an application using the OpenAI Python SDK, this is the only code change needed:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://inference.ionext.ai/v1",   # was: OpenAI's default
    api_key=os.environ["IONEXT_API_KEY"],         # was: OPENAI_API_KEY
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B-FP8",                 # was: a GPT model
    messages=[
        {"role": "user", "content": "Explain Indonesia's PDP Law in three sentences."}
    ],
    temperature=0.6,
    max_tokens=1024,
)

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

Without an SDK, a plain HTTP request works too. The example below uses the requests library:

import os
import requests

url = "https://inference.ionext.ai/v1/chat/completions"

headers = {
    "Accept": "application/json",
    "Content-Type": "application/json",
    "Authorization": f"Bearer {os.environ['IONEXT_API_KEY']}",
}

payload = {
    "model": "Qwen/Qwen3.8-27B-FP8",
    "max_tokens": 4096,
    "temperature": 0.6,
    "messages": [
       {"role": "user", "content": "Explain Indonesia's PDP Law in three sentences."}
    ],
}

response = requests.post(url, headers=headers, json=payload)
print(response.json())

A note on third-party tools: some ask for a base URL (https://inference.ionext.ai/v1), others ask for the full endpoint URL (https://inference.ionext.ai/v1/chat/completions). If a connection fails, try the other form.

4. Check the available models

for model in client.models.list():
    print(model.id)

Use the model name exactly as it appears here, including the Qwen/ prefix.

5. Test with the actual use case

The same format does not guarantee the same answers. The section below details what to test.

What to test before going to production

What most often differs after switching endpoints is answer quality, tool-calling behavior, and the parts of the pipeline that did not move with it, such as embedding and tracing. Test the five areas below with data from the actual use case, not demo prompts.

• Answer quality. Qwen is not GPT. Put together a small evaluation set of real client questions, say 30 to 50 examples, and compare results before and after the switch. Some system prompts may need adjustment.
• Function calling. Confirm the model picks the right tool and that the arguments it produces pass the application's schema validation.
• Structured output. Keep validating JSON on the application side, the same way as with any other provider.
• Embeddings for RAG. The embeddings endpoint is not available on this API yet. Run an embedding model separately, for example on a GPU VM in Jakarta, so document chunks are not sent abroad. We cover the pattern in RAG Architecture That Keeps Data in Indonesia.
• Data flows outside the model. Tracing, logging, and evaluation tools left on from prototyping often keep sending full prompts to a service abroad after go-live. Check every integration, not just the model endpoint.

Does switching endpoints automatically make a project PDP Law compliant?

No. Where the model processes data is one component of compliance, not all of it. A project still needs a lawful basis for processing, a data protection impact assessment (DPIA) where required, contracts with sub-processors, and clear access controls. Moving inference to Indonesia removes one major question from review, the cross-border transfer of personal data for model processing, so the conversation with the client's legal team can focus on what remains.

Where to start

For a team preparing a project for a client that requires data to be processed in Indonesia, sign up at the console, then contact the IONext team for API access activation. GPU specs and model memory fit are on the GPU page, and how IONext monitors the infrastructure running a model is explained in ORBIT.