Catatan penulis: Jika curl berhasil tetapi klien mengalami 401, 404, 400, atau gagal terhubung, periksa 7 titik pada layanan proksi API dalam urutan yang tetap. Artikel ini juga menyertakan tabel kode kesalahan dan daftar pemeriksaan 10 menit.
Dengan Key dan model yang sama, permintaan curl bisa mendapat respons 200, tetapi Cherry Studio, Chatbox, Cursor, Cline, Claude Code, atau Codex CLI justru melaporkan 401, 404, 400, atau langsung mengalami timeout maupun respons kosong. Dalam situasi ini, periksa konfigurasi klien terlebih dahulu, jangan buru-buru mengganti Key. Keberhasilan curl membuktikan bahwa Key valid dan jaringan dapat dijangkau. Kemungkinan besar, permintaan yang benar-benar dikirim klien berbeda dari yang Anda kira.
Urutan pemeriksaan yang disarankan adalah: Base URL → protokol dan endpoint → header autentikasi → ID model → isi permintaan → jaringan. Sebelum itu, pastikan dulu apakah klien benar-benar membaca konfigurasi yang sudah Anda ubah. Artikel ini membagi alur permintaan tersebut menjadi 7 titik pemeriksaan. Setiap titik dibahas berdasarkan “gejala, penyebab, cara memverifikasi, dan cara memperbaiki”, agar Anda bisa mengetahui dalam 10 menit apakah masalahnya ada di klien, gateway, atau layanan upstream.
Ini bukan sekadar artikel lain yang menjelaskan teori API, melainkan panduan pemecahan masalah yang bisa langsung Anda ikuti.
Mengapa curl Berhasil, tetapi Klien Tidak Bisa Terhubung: Hal Penting untuk Memeriksa Layanan Proksi API
curl hanya memverifikasi sebagian kecil dari jalur permintaan: resolusi DNS, handshake TLS, keterjangkauan jaringan, validitas Key, dan ketersediaan satu endpoint yang kamu minta secara manual. curl tidak memverifikasi apakah klien membaca konfigurasi yang sudah kamu ubah, bagaimana klien menyusun Base URL, atau apakah header dan body permintaan klien sama dengan permintaan curl.
Secara umum, permintaan dari klien melewati jalur berikut: konfigurasi klien (variabel lingkungan, file konfigurasi, GUI) → penyusunan Base URL → protokol dan endpoint → header autentikasi → ID dan pemetaan model → body permintaan (pesan, tool, multimodal, streaming) → proksi, TLS, jaringan → gateway → model upstream. Keberhasilan curl hanya menunjukkan bahwa jalur yang kamu tulis secara manual bisa dilalui. Klien bisa saja menggunakan jalur yang sama sekali berbeda.
| Titik pemeriksaan | Gejala umum | Cara verifikasi yang diprioritaskan |
|---|---|---|
| 1. Pembacaan konfigurasi | Perubahan konfigurasi tidak berlaku, error sama seperti sebelumnya | Periksa URL permintaan yang sebenarnya di log klien |
| 2. Penyusunan Base URL | 404, jalur mengandung /v1/v1 atau // |
Bandingkan URL di log dengan URL curl |
| 3. Protokol dan endpoint | 404, 400, atau gagal mengurai format respons | Pastikan protokol yang digunakan klien |
| 4. Header autentikasi | 401, tetapi Key berfungsi di curl | Bandingkan perbedaan header permintaan |
| 5. ID model | 404 atau 400, dengan pesan bahwa model tidak ditemukan | Bandingkan persis dengan daftar model di gateway |
| 6. Body permintaan | Teks biasa berhasil, tetapi penambahan gambar atau tool menghasilkan 400 | Tambahkan variabel satu per satu untuk mereproduksi masalah |
| 7. Jaringan dan streaming | Timeout, stream disconnected, atau respons kosong | Bandingkan dengan streaming dimatikan, lalu periksa proksi |
Pemeriksaan proksi API 1–2: Pembacaan konfigurasi klien dan penggabungan Base URL
Pemeriksaan 1: Apakah klien benar-benar membaca konfigurasi yang diubah?
Gejala: Base URL dan kunci API sudah diganti, tetapi pesan kesalahannya tetap sama; atau konfigurasi berfungsi di satu proyek, tetapi tidak di proyek lain.
Penyebab: Sebagian besar klien membaca konfigurasi dari lebih dari satu sumber. Contohnya, pengaturan GUI menimpa variabel lingkungan; file konfigurasi memiliki beberapa profil dan profil yang aktif bukan yang Anda ubah; konfigurasi proyek menimpa konfigurasi global; atau proses lama belum ditutup sehingga masih menggunakan nilai yang dimuat saat dimulai. Kasus terakhir sering terjadi pada alat baris perintah: variabel lingkungan sudah diubah di terminal, tetapi proses IDE atau Agent yang sudah berjalan tidak bisa melihat perubahannya.
Cara memeriksa: Buka log klien atau output debug, lalu pastikan URL permintaan dan beberapa karakter awal kunci API sesuai dengan nilai yang baru Anda masukkan. Jika log sulit diakses, coba ubah Base URL menjadi alamat yang jelas salah dan lihat apakah pesan kesalahannya berubah. Dengan begitu, Anda bisa memastikan apakah perubahan konfigurasi sudah diterapkan.
Cara memperbaiki: Cari tahu urutan prioritas konfigurasi klien. Biasanya, konfigurasi GUI atau proyek lebih tinggi daripada file konfigurasi global, dan file konfigurasi lebih tinggi daripada variabel lingkungan. Namun, aturannya berbeda untuk setiap klien, jadi ikuti dokumentasinya. Ubah konfigurasi hanya di sumber dengan prioritas tertinggi, hapus entri yang bertentangan di sumber lain, lalu tutup proses klien sepenuhnya sebelum memulainya kembali.
Pemeriksaan 2: Garis miring di akhir Base URL, duplikasi /v1, dan prefiks jalur
Gejala: Muncul kesalahan 404, dan URL di log berisi /v1/v1/chat/completions, //chat/completions, atau menjadi /v1/chat/completions/chat/completions.
Penyebab: Setiap klien bisa menafsirkan kolom Base URL secara berbeda. Ada klien yang meminta alamat dasar lalu menambahkan /v1 sendiri; ada yang meminta alamat sampai /v1 lalu menambahkan /chat/completions; ada juga yang memisahkan Base URL dan endpoint lengkap ke dalam dua kolom. Jika Anda memasukkan seluruh https://api.apiyi.com/v1/chat/completions ke kolom yang hanya menerima prefiks, atau menambahkan garis miring setelah alamat yang sudah berisi /v1, jalur yang dihasilkan bisa salah.
Cara memeriksa: Bandingkan URL permintaan lengkap di log dengan URL yang Anda gunakan di curl, karakter demi karakter. Perhatikan berapa kali /v1 muncul, apakah ada garis miring ganda, dan apakah ada segmen jalur tambahan di akhir.
Cara memperbaiki: Isi sesuai dokumentasi klien. Untuk klien yang kompatibel dengan OpenAI, biasanya gunakan https://api.apiyi.com/v1 tanpa garis miring di akhir. Jika klien menambahkan /v1 secara otomatis, hapus /v1 yang Anda masukkan. Setelah itu, periksa kembali URL di log dan pastikan jalur akhirnya mengikuti bentuk standar seperti https://api.apiyi.com/v1/chat/completions.
🎯 Saran konfigurasi: Alamat APIYI (apiyi.com) yang kompatibel dengan OpenAI adalah
https://api.apiyi.com/v1, dengan format yang sama seperti pada SDK OpenAI resmi. Daftar model yang tersedia bisa dilihat di konsol atau diperoleh melalui endpoint daftar model menggunakan Base URL yang sama. Gunakan endpoint tersebut untuk memastikan kunci API dan alamat sudah benar sebelum mengonfigurasi klien.
Pemeriksaan layanan proksi API 3-4: Endpoint protokol dan header autentikasi
Poin pemeriksaan 3: Apakah protokol dan endpoint cocok?
Gejala: Base URL terlihat benar, tetapi masih muncul 404 atau 400. Bisa juga permintaan berhasil, tetapi klien melaporkan “tidak dapat mengurai respons” atau mengembalikan konten kosong.
Penyebab: Saat ini, antarmuka Model Bahasa Besar menggunakan lebih dari satu protokol. Misalnya, klien hanya mendukung Chat Completions, tetapi diarahkan ke endpoint yang hanya menyediakan Responses. Claude Code menggunakan protokol Anthropic Messages, bukan OpenAI Chat Completions. Sementara itu, format native Gemini dan format yang kompatibel dengan OpenAI memiliki path dan body permintaan yang sama sekali berbeda. Di curl, Anda mungkin menulis endpoint yang benar secara manual, tetapi klien bisa saja mengirim permintaan menggunakan protokol default-nya sendiri.
| Jenis protokol | Path endpoint umum | Pengguna umum | Metode autentikasi |
|---|---|---|---|
| OpenAI Chat Completions | /v1/chat/completions |
Berbagai klien seperti Cherry Studio, Chatbox, dan Cline | Authorization: Bearer |
| OpenAI Responses | /v1/responses |
Tool ekosistem OpenAI versi terbaru | Authorization: Bearer |
| Anthropic Messages | /v1/messages |
Tool native Anthropic seperti Claude Code | x-api-key ditambah anthropic-version |
| Gemini native | Antarmuka native yang menggunakan nama model sebagai path | SDK native Gemini | Mengacu pada dokumentasi resmi dan gateway |
Cara memeriksa: Lihat bagian akhir path permintaan di log klien untuk mengetahui protokol yang digunakan. Lalu, pastikan endpoint gateway yang dipilih mendukung protokol tersebut. Jika klien memiliki menu pilihan “jenis penyedia” atau “format API”, pastikan pilihannya sesuai dengan protokol yang ingin digunakan.
Cara memperbaiki: Pastikan jenis protokol klien, Base URL, dan model saling sesuai. Untuk format yang kompatibel dengan OpenAI, pilih penyedia jenis OpenAI. Untuk tool native seperti Claude Code, gunakan konfigurasi protokol Anthropic. Jika membutuhkan kemampuan native Gemini, gunakan konfigurasi format Gemini. APIYI mendukung format yang kompatibel dengan OpenAI serta format API native seperti Claude dan Gemini. Untuk alamat integrasi masing-masing format native, lihat dokumentasi di docs.apiyi.com; jangan menyusun path berdasarkan ingatan.
Poin pemeriksaan 4: Apakah header autentikasi sesuai dengan protokol?
Gejala: Muncul error 401, tetapi Key yang sama berfungsi dengan baik di curl.
Penyebab: Antarmuka yang kompatibel dengan OpenAI umumnya menggunakan Authorization: Bearer <Key>, sedangkan antarmuka native Anthropic umumnya menggunakan x-api-key ditambah anthropic-version. Beberapa platform juga memerlukan header terkait organisasi atau proyek. Header yang Anda tulis di curl mungkin sudah benar, tetapi klien bisa saja mengirim header lain sesuai protokol yang berbeda, atau menyertakan header organisasi yang tidak dikenali gateway sehingga autentikasi gagal.
Cara memeriksa: Bandingkan header permintaan di curl dan log klien, terutama field seperti Authorization, x-api-key, Content-Type, dan OpenAI-Beta. Periksa juga apakah ada spasi, baris baru, atau tanda kutip berlebih sebelum atau sesudah Key. Hal ini sering terjadi saat menyalin dan menempel dari halaman web.
Cara memperbaiki: Gunakan header autentikasi yang sesuai dengan protokol. Jika protokolnya sudah benar, sebagian besar klien akan otomatis mengirim header yang tepat. Jika klien memungkinkan header kustom, hapus header organisasi atau proyek yang tidak diperlukan. Tempel ulang Key dan pastikan tidak ada karakter tambahan.
Poin Pemeriksaan 5–7 Layanan Proksi API: ID Model, Isi Permintaan, dan Streaming Jaringan
Pemeriksaan 5: ID dan Pemetaan Model
Gejala: Muncul error 404 atau 400 yang menyatakan model tidak ada atau tidak valid. Bisa juga hanya satu model yang gagal, sementara model lain berfungsi normal.
Penyebab: ID model harus sama persis dengan yang ada di daftar model gateway. Perbedaan yang sering terjadi meliputi huruf besar dan kecil, akhiran versi, format awalan (misalnya provider/model), dan alias. Nama model yang sama bisa berbeda di setiap platform. Bisa juga ID yang Anda butuhkan tidak ada dalam daftar bawaan klien, sehingga klien diam-diam menggantinya dengan nilai default.
Cara memeriksa: Salin ID model dari antarmuka daftar model atau konsol gateway, lalu bandingkan karakter demi karakter dengan kolom model pada isi permintaan di log klien. Jika hanya satu model yang gagal, periksa dulu apakah ID model dan endpoint sudah sesuai, lalu pastikan akun Anda punya akses ke model tersebut.
Cara memperbaiki: Tambahkan model kustom secara manual di klien, lalu tempel langsung ID dari gateway—jangan ketik sendiri. Jika klien melakukan pemetaan model, pastikan nama hasil pemetaannya benar.
💡 Saran untuk ID model: Saat menggunakan satu kunci API melalui APIYI apiyi.com untuk memanggil model dari berbagai penyedia seperti OpenAI, Claude, Gemini, DeepSeek, dan Qwen, gunakan ID yang tercantum dalam daftar model di konsol. Nama model yang sama bisa berbeda di setiap platform, jadi menyalinnya dari konsol adalah cara termudah untuk menghindari kesalahan. Periksa juga ketersediaan model di konsol dan dokumentasi.
Titik pemeriksaan 6: Body permintaan dan format multimodal
Gejala: Percakapan teks biasa berjalan normal, tetapi muncul kesalahan 400 saat mengirim gambar, memanggil tool, atau mengaktifkan parameter reasoning.
Penyebab: Masalah kompatibilitas body permintaan biasanya muncul pada struktur array content multimodal, penulisan field image_url, atau gambar base64 yang tidak memiliki awalan MIME seperti data:image/png;base64,. Format field pemanggilan tool mungkin tidak sesuai dengan protokol yang digunakan. Persyaratan max_tokens dan max_completion_tokens juga berbeda antar-model, sementara parameter terkait reasoning hanya diterima oleh sebagian model. Parameter dari penyedia yang berbeda tidak selalu bisa digunakan secara bergantian.
Cara memeriksa: Tambahkan variabel satu per satu. Mulai dengan teks biasa; jika berhasil, aktifkan streaming, lalu tambahkan pemanggilan tool, dan terakhir multimodal. Uji setiap kali menambahkan variabel. Field yang menyebabkan masalah ada pada langkah pertama yang gagal. Pesan kesalahan biasanya menyebutkan field tersebut, jadi pastikan untuk membaca respons kesalahan secara lengkap.
Cara memperbaiki: Nonaktifkan parameter lanjutan yang tidak diperlukan di klien, lalu sesuaikan field dengan dokumentasi model tujuan. Gunakan awalan base64 yang sesuai atau URL yang dapat diakses untuk gambar, dan tulis definisi tool sesuai format protokol yang digunakan.
Titik pemeriksaan 7: Jaringan, proksi, TLS, dan buffering streaming
Gejala: Koneksi mengalami timeout, muncul stream disconnected, respons kosong setelah lama tidak ada tanggapan, atau permintaan non-streaming berhasil tetapi streaming gagal.
Penyebab: Klien mungkin menggunakan proksi sistem atau proksi dari variabel lingkungan, sedangkan curl tidak, atau sebaliknya. Firewall perusahaan, validasi sertifikat TLS, resolusi IPv6, dan DNS juga bisa membuat klien gagal terhubung. Pada streaming, beberapa proksi menahan respons dalam buffer dan baru meneruskannya setelah seluruh konten diterima. Akibatnya, klien tidak menerima data dan menganggap koneksi timeout atau terputus.
Cara memeriksa: Bedakan dulu antara “koneksi belum terbentuk” dan “stream terputus”. Untuk kasus pertama, periksa apakah ada kesalahan TLS atau koneksi; pada kasus kedua, biasanya sebagian konten sudah diterima. Coba lagi tanpa streaming. Jika non-streaming berjalan normal, kemungkinan besar masalahnya ada pada buffering proksi atau pengaturan timeout. Periksa juga apakah variabel lingkungan proksi di klien dan terminal sudah sama.
Cara memperbaiki: Samakan pengaturan proksi klien dan curl; hindari proksi yang melakukan buffering untuk permintaan streaming; dan perpanjang timeout klien secukupnya. Jika koneksi upstream sesekali terputus, coba ulang dalam jumlah terbatas atau beralih sementara ke model lain untuk memeriksa apakah masalahnya hanya terjadi pada satu upstream.
Panduan Cepat Layanan Proksi API: Tabel Kode Kesalahan dan Daftar Periksa Konfigurasi Klien
Saat menemukan kesalahan, gunakan kode kesalahan untuk mempersempit kemungkinan penyebab, lalu periksa konfigurasi satu per satu.
Tabel Kode Kesalahan
| Kode kesalahan | Penyebab umum | Prioritas pemeriksaan |
|---|---|---|
| 401 | Kunci API tidak valid, kedaluwarsa, atau dinonaktifkan; format header permintaan salah; organisasi atau proyek tidak cocok | Poin pemeriksaan 1, 4 |
| 403 | Kunci API valid, tetapi ditolak oleh kebijakan model, organisasi, atau wilayah; daftar putih IP; akses model belum diaktifkan | Poin pemeriksaan 5, izin akun |
| 404 | Jalur Base URL salah; endpoint atau ID model tidak ada; gateway belum mengimplementasikan rute tersebut | Poin pemeriksaan 2, 3, 5 |
| 400 | Isi permintaan, parameter, ID model, atau field multimodal tidak valid; parameter vendor tidak kompatibel | Poin pemeriksaan 5, 6 |
| 429 | Batas laju tercapai atau kuota tidak mencukupi | Periksa Retry-After, lakukan backoff atau ganti model |
| 500/502/503/529 | Kesalahan pada upstream atau gateway; 529 biasanya muncul saat kelebihan beban | Coba ulang dalam jumlah terbatas, periksa log gateway |
| Timeout, stream disconnected | Gangguan jaringan, proksi, TLS, atau upstream | Poin pemeriksaan 7 |
Daftar Periksa Konfigurasi Klien
| Poin pemeriksaan | Hal yang perlu dipastikan |
|---|---|
| Sumber konfigurasi | Apakah yang diubah adalah variabel lingkungan, file konfigurasi, atau GUI? Mana yang prioritasnya paling tinggi? Apakah ada beberapa profil atau konfigurasi proyek yang saling menimpa? |
| Base URL | Apakah mencakup /v1? Apakah klien menambahkan /v1 secara otomatis? Apakah ada garis miring berlebih di akhir? |
| Jenis endpoint | Chat Completions, Responses, atau endpoint native Claude atau Gemini? Apakah versi klien mendukungnya? |
| Header autentikasi | Apakah menggunakan Authorization: Bearer atau x-api-key? Apakah anthropic-version diperlukan? |
| ID model | Apakah sama persis dengan daftar model gateway, termasuk huruf besar-kecil dan prefiks? |
| Isi permintaan | Apakah mencakup tool, gambar, atau parameter reasoning? Apakah field max_tokens sesuai dengan model tujuan? |
| Streaming dan jaringan | Apakah streaming diaktifkan? Apakah proksi melakukan buffering? Apakah pengaturan proksi klien dan curl sama? |
Bandingkan dengan Permintaan Minimal
Cara paling efektif adalah membandingkan dengan variabel yang dikendalikan: gunakan Base URL, kunci API, model, dan isi permintaan yang sama. Kirim terlebih dahulu dengan curl, lalu dengan klien. Langkah-langkahnya:
- Gunakan endpoint daftar model untuk memverifikasi kunci API dan Base URL, misalnya dengan meminta
https://api.apiyi.com/v1/models; - Gunakan satu permintaan chat teks sederhana untuk memverifikasi endpoint dan ID model;
- Aktifkan streaming untuk memverifikasi jaringan dan proksi;
- Tambahkan pemanggilan tool atau input multimodal untuk memverifikasi isi permintaan;
- Pada setiap langkah, periksa log klien dan log di sisi gateway.
🚀 Saran pemecahan masalah: Konsol APIYI menampilkan statistik penggunaan dan log pemanggilan terperinci. Jika klien melaporkan kesalahan tetapi tidak ada catatan pemanggilan tersebut di konsol, berarti permintaan tidak mencapai gateway dan masalahnya ada pada konfigurasi klien atau jaringan lokal. Jika ada catatan beserta pesan kesalahan, gunakan log untuk menentukan apakah masalahnya ada pada parameter atau upstream.
Pertanyaan Umum FAQ
Q1: Jika curl berhasil tetapi klien tidak bisa terhubung, apakah mengganti Key membantu?
Biasanya tidak. Keberhasilan curl sudah membuktikan bahwa Key valid. Jika masalah teratasi setelah mengganti Key, sering kali itu karena klien ikut dimulai ulang atau profil diganti, sehingga konfigurasi dimuat ulang. Daripada mengganti Key, tutup klien sepenuhnya dan mulai ulang, lalu periksa Base URL dan Key yang benar-benar digunakan di log. Anda juga bisa memeriksa status dan riwayat pemanggilan Key tersebut di konsol APIYI untuk memastikan apakah memang ada masalah dengan Key.
Q2: Mengapa endpoint /models bisa diakses, tetapi permintaan chat gagal?
Endpoint daftar model hanya memastikan bahwa autentikasi dan Base URL pada dasarnya sudah benar. Endpoint ini tidak memeriksa endpoint chat, ID model, atau isi permintaan. Jika chat gagal, periksa secara berurutan: apakah protokol yang digunakan klien sesuai dengan endpoint (titik pemeriksaan 3), apakah ID model sama persis dengan yang ada di daftar (titik pemeriksaan 5), dan apakah isi permintaan menyertakan parameter yang tidak didukung model tujuan (titik pemeriksaan 6).
Q4: Jika hanya satu model yang gagal sementara model lain normal, apa yang perlu diperiksa terlebih dahulu?
Periksa ID model dan endpoint terlebih dahulu, lalu izin akun. Perbedaan huruf besar-kecil, prefiks, dan alias pada ID model adalah penyebab yang paling umum. Kemungkinan berikutnya, model tersebut memerlukan protokol yang berbeda, seperti format native. Setelah itu, periksa masalah izin atau ketersediaan. Dengan satu Key APIYI, Anda bisa beralih antara model dari berbagai penyedia. Coba sementara model sejenis sebagai pembanding untuk mengetahui dengan cepat apakah masalahnya ada pada satu model atau pada konfigurasi secara keseluruhan.
Q5: Bagaimana membedakan masalah klien dan masalah gateway?
Perhatikan dua hal utama: apakah gateway menerima permintaan, dan apakah permintaan yang sama berhasil saat dikirim dengan curl. Jika tidak ada catatan di gateway, kemungkinan besar masalahnya ada pada klien atau jaringan lokal. Jika permintaan yang sama berhasil lewat curl tetapi gagal di klien, kemungkinan besar masalahnya ada pada cara klien menyusun permintaan atau isi permintaannya. Jika permintaan yang sama juga gagal lewat curl dan log menunjukkan 5xx, barulah Anda perlu menghubungi dukungan gateway.
Kesimpulan: Daftar Periksa Layanan Proksi API dalam 10 Menit dan Kapan Mencari Bantuan
Jika “curl berhasil, tetapi klien tidak bisa terhubung”, jangan buru-buru mengganti Key. Periksa hal-hal berikut dalam 10 menit:
- Periksa log klien: Dapatkan URL, header, dan body permintaan yang sebenarnya, lalu pastikan konfigurasi sudah diterapkan;
- Periksa Base URL: Pastikan
/v1hanya muncul sekali, tidak ada garis miring ganda, dan tidak ada segmen path yang berulang; - Periksa protokol endpoint: Pastikan Chat Completions, Responses, Claude Messages, atau format native Gemini sesuai dengan jenis klien;
- Periksa header autentikasi: Gunakan
Authorization: Bearerataux-api-key, hapus header organisasi yang tidak diperlukan dan spasi di kedua ujung Key; - Periksa ID model: Bandingkan karakter demi karakter dengan daftar model di gateway;
- Kirim permintaan minimal: Gunakan Key, model, dan body permintaan yang sama, lalu kirim masing-masing sekali lewat curl dan klien untuk dibandingkan;
- Tambahkan streaming: Jika gagal, periksa buffering dan timeout proksi;
- Tambahkan tool atau multimodal: Jika gagal, periksa field pada body permintaan;
- Tentukan sumber masalah: Gunakan log gateway untuk menentukan apakah masalah ada di klien atau gateway.
Kapan masalahnya merupakan bug klien: Tidak ada catatan pemanggilan di gateway, atau curl berhasil menggunakan URL, header, dan body permintaan yang persis sama, tetapi klien gagal. Pastikan juga konfigurasinya benar dan versi klien mendukung endpoint yang digunakan. Dalam kondisi ini, perbarui versi klien atau laporkan masalah ke proyek klien.
Kapan perlu menghubungi dukungan gateway: Permintaan minimal yang sama juga gagal lewat curl, dan log gateway menunjukkan catatan pemanggilan dengan respons 5xx. Atau, satu model terus mengalami error sementara model lain berjalan normal, dan Anda sudah memastikan ID model serta izin akses bukan penyebabnya. Saat menghubungi dukungan, sertakan waktu permintaan, ID model, kode error, dan pesan error dalam log agar masalah lebih cepat ditemukan.
Untuk perangkat tim yang membutuhkan stabilitas, penggunaan beberapa model dan jalur juga membantu penelusuran masalah. Saat satu model atau jalur bermasalah, beralihlah ke model lain untuk uji perbandingan agar cakupan masalah langsung terlihat. APIYI apiyi.com memungkinkan akses ke format yang kompatibel dengan OpenAI serta format native Claude dan Gemini menggunakan satu Key. Penggunaan dan log di konsol juga membantu verifikasi dengan cepat; harga dan ketersediaan mengacu pada konsol dan dokumentasi.
Penulis: Tim Teknis APIYI
Diskusi teknis: Silakan hubungi kami melalui halaman utama situs APIYI
