Base URL API OpenAI (2026): Endpoint Langsung dan Kompatibel

Base URL API OpenAI (2026): Endpoint Langsung dan Kompatibel

Jawaban singkat: base URL API OpenAI resmi adalah https://api.openai.com/v1. Gunakan sebagai base_url atau baseURL SDK, lalu biarkan SDK menambahkan jalur resource. Endpoint lengkap yang umum adalah https://api.openai.com/v1/responses dan https://api.openai.com/v1/chat/completions.

Untuk gateway yang kompatibel dengan OpenAI milik Flatkey, gunakan https://router.flatkey.ai/v1 sebagai base URL. Endpoint chat-completions yang sesuai adalah https://router.flatkey.ai/v1/chat/completions. Jangan tempelkan jalur lengkap /chat/completions ke dalam kolom SDK yang hanya mengharapkan base URL.

Tabel base URL API OpenAI

Base URL vs endpoint: perbedaannya

Base URL adalah awalan bersama yang dikonfigurasi sekali dalam SDK. Endpoint adalah jalur lengkap untuk satu operasi API. Mencampurkan keduanya menyebabkan kegagalan integrasi yang paling umum:

• 404 Not Found: Anda memberikan jalur yang salah atau menduplikasi /v1.
• 401 Unauthorized: key tersebut tidak termasuk dalam base URL yang Anda panggil.
• /v1/v1/...: base URL yang dikonfigurasi dan kode klien Anda sama-sama menambahkan /v1.
• .../chat/completions/chat/completions: endpoint lengkap diberikan di tempat SDK hanya mengharapkan base URL.

Gunakan satu sumber kebenaran untuk base URL, simpan key dalam variabel lingkungan, dan jalankan permintaan /models atau chat kecil sebelum memigrasikan traffic produksi.

Apa yang diubah oleh gateway API yang kompatibel dengan OpenAI

Perubahan utamanya bersifat operasional, bukan konseptual.

Itulah alasan tim mencari openai compatible api gateway sejak awal. Mereka tidak meminta format prompt baru. Mereka meminta risiko penulisan ulang yang lebih kecil.

Gunakan daftar periksa migrasi ini sebelum mengubah produksi

Cara paling aman untuk mengadopsi openai compatible api gateway adalah memperlakukannya sebagai perubahan integrasi yang terkontrol, bukan proyek abstraksi menyeluruh.

1. Daftarkan endpoint OpenAI persis yang Anda gunakan saat ini. Sebagian besar tim mengira mereka menggunakan “API OpenAI”, padahal sebenarnya mereka menggunakan subset yang lebih kecil seperti chat completions, responses, embeddings, atau pembuatan gambar.
2. Konfirmasikan panggilan mana yang harus tetap tidak berubah dalam kode aplikasi. Ini menjaga ruang lingkup tetap jujur dan melindungi klaim “migrasi minimal”.
3. Periksa apakah SDK Anda saat ini sudah mendukung base URL kustom. Klien OpenAI Python dan Node resmi saat ini mendukungnya.
4. Pilih satu alur kerja staging terlebih dahulu. Mulailah dengan rute yang sudah sesuai dengan bentuk permintaan OpenAI standar.
5. Verifikasikan model target secara langsung sebelum peluncuran. Jangan mengandalkan tangkapan layar lama atau asumsi katalog yang usang.
6. Tuliskan aturan fallback. Peninjau harus mengetahui apakah rute dapat mengganti model, gagal tertutup, atau masuk antrean.
7. Setujui catatan kompatibilitas. Pernyataan publik Anda harus menyebut “OpenAI-compatible” untuk permukaan permintaan yang didukung, bukan “sepenuhnya identik dengan OpenAI.”

Daftar periksa inilah yang membuat openai compatible api gateway kredibel untuk peninjauan produksi.

Contoh kode dengan perubahan minimal

SDK OpenAI resmi saat ini sudah mendokumentasikan dukungan base URL kustom. Itulah alasan mekanis mengapa openai compatible api gateway dapat menjadi migrasi dengan gesekan rendah ketika gateway mempertahankan bentuk permintaan bergaya OpenAI yang sudah Anda gunakan.

Contoh Python

from openai import OpenAI

client = OpenAI(
    api_key="sk-fk-your-flatkey-key",
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Return a one-line health check."},
    ],
)

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

Contoh Node

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-5.4-mini",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "Return a one-line health check." },
  ],
});

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

Contoh cURL

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [
      { "role": "user", "content": "Return a one-line health check." }
    ]
  }'

Bagi banyak tim, ini adalah bukti awal bahwa API gateway yang kompatibel dengan OpenAI tidak selalu mengharuskan penulisan ulang klien. Batasan pentingnya adalah alur kerja yang Anda pilih harus sesuai dengan cakupan permintaan yang didukung.

Hal yang perlu diverifikasi sebelum menyebut migrasi sebagai “drop-in”

Di sinilah sebagian besar halaman tentang API gateway yang kompatibel dengan OpenAI kurang cermat. Istilah “drop-in” terlalu luas kecuali Anda menentukan batasannya.

Gunakan tabel ini dalam peninjauan:

API gateway yang kompatibel dengan OpenAI bernilai ketika pemeriksaan ini dapat dilewati dengan lebih sedikit hambatan dibandingkan migrasi penyedia secara terpisah.

Urutan peluncuran yang praktis

Berikut adalah jalur peluncuran paling sederhana untuk API gateway yang kompatibel dengan OpenAI jika Anda menginginkan perubahan kode seminimal mungkin:

1. Inventarisasi jalur panggilan saat ini. Catat versi SDK saat ini, kelompok endpoint, ID model, pengaturan streaming, dan asumsi percobaan ulang.
2. Ubah satu base URL di staging. Pertahankan pola klien yang sama terlebih dahulu. Jangan gabungkan langkah ini dengan perubahan prompt atau model yang tidak terkait.
3. Gunakan satu model yang disetujui untuk pengujian pertama. Kriteria keberhasilan pertama adalah kompatibilitas transport, bukan cakupan model yang luas.
4. Periksa respons dan struktur error. Bandingkan output, kode status, ekspektasi latensi, dan perilaku pencatatan log.
5. Tinjau kebijakan routing model. Putuskan apakah rute ditetapkan ke satu model, dapat beralih ke kelas yang setara saat terjadi kegagalan, atau harus menolak permintaan saat terjadi kegagalan.
6. Perluas hanya setelah mengonfirmasi katalog yang aktif. Pada 15 Juli 2026, feed harga publik Flatkey menampilkan total 170 baris dan 95 baris yang tersedia, tetapi peluncuran produksi tetap memerlukan validasi model yang tepat pada hari Anda melakukan peluncuran.

Urutan itulah yang menjadikan API gateway yang kompatibel dengan OpenAI sebagai lapisan kendali migrasi, bukan tambahan ketidakpastian dalam integrasi.

Perbedaannya dengan migrasi langsung ke penyedia

Dokumentasi penyedia sudah menunjukkan bahwa kompatibilitas bergaya OpenAI semakin lazim. Google mendokumentasikan akses Gemini melalui pustaka OpenAI. DeepSeek mendokumentasikan kompatibilitas dengan OpenAI dan Anthropic. Namun, setiap penyedia tetap memiliki kunci, base URL, dan batas operasionalnya sendiri.

Itulah kesenjangan yang diatasi oleh API gateway yang kompatibel dengan OpenAI. Alih-alih mengajarkan konfigurasi khusus penyedia yang baru kepada setiap tim, Anda dapat memusatkan cakupan migrasi dan mengalihkan pekerjaan peninjauan ke persetujuan model, observabilitas, dan kebijakan routing model.

Ini juga menjelaskan mengapa pesan Flatkey saat ini lebih kuat daripada sekadar “berfungsi dengan SDK OpenAI”. Manfaat yang lebih penting adalah bahwa API gateway yang kompatibel dengan OpenAI dapat mengonsolidasikan akses dan peninjauan tanpa memaksa penulisan ulang aplikasi secara langsung.

Rumusan kepatuhan yang dapat disetujui peninjau

Gunakan rumusan seperti berikut dalam peninjauan akhir sebelum publikasi:

Hindari frasa seperti ini kecuali peninjau dapat membuktikannya:

Peringatan ini membuat narasi gateway API yang kompatibel dengan OpenAI lebih kredibel, bukan lebih lemah.

Kapan gateway API yang kompatibel dengan OpenAI merupakan pilihan yang tepat

Sebuah gateway API yang kompatibel dengan OpenAI biasanya merupakan pilihan yang tepat ketika:

• tim Anda sudah mengandalkan alur klien bergaya OpenAI dan menginginkan jalur migrasi yang paling minim gangguan
• lebih dari satu keluarga model sudah masuk dalam cakupan
• Anda memerlukan satu tempat untuk meninjau akses, penggunaan, dan rute yang disetujui
• perubahan model cukup sering terjadi sehingga memerlukan kebijakan perutean model bersama
• Anda menginginkan migrasi terkontrol sebelum mempertimbangkan fitur gateway yang lebih mendalam

Jika kondisi tersebut tidak terpenuhi, penyiapan penyedia secara langsung mungkin masih lebih sederhana. Artikel ini harus tetap jujur mengenai pertukaran tersebut.

Tim AWS: base URL yang kompatibel dengan OpenAI dari Bedrock

Jika model Anda berjalan di AWS, Amazon Bedrock menyediakan base URL-nya sendiri yang kompatibel dengan OpenAI, https://bedrock-runtime.{region}.amazonaws.com/openai/v1, yang diautentikasi dengan kunci API Bedrock. Panduan API Amazon Bedrock yang kompatibel dengan OpenAI kami membahas endpoint, kunci, ID model, dan batasan /models.

Kesimpulan

Nilai dari sebuah gateway API yang kompatibel dengan OpenAI bukanlah karena gateway tersebut menciptakan pola API baru. Nilainya adalah gateway ini memungkinkan tim mempertahankan integrasi bergaya OpenAI yang familier sambil memindahkan akses, persetujuan model, dan kontrol peluncuran ke balik satu lapisan yang dapat ditinjau.

Bagi Flatkey, klaim terkuat yang dapat ditinjau adalah sederhana: pertahankan pola klien yang sudah Anda gunakan, ubah base URL menjadi https://router.flatkey.ai/v1, validasi alur kerja tepat yang didukung, dan setujui kebijakan perutean model sebelum Anda memperluas trafik. Itulah daftar periksa migrasi yang benar-benar dibutuhkan pengembang.