Skip to content
Konsultasi

Skrip Riset Tahan Gagal: Rotasi API Key Dua Provider

Adityo Guni Waluyo

Rotasi API key dua lapis, fallback provider, dan DoH buat DNS ISP yang dibelokkan: pelajaran bikin skrip riset yang nggak gampang mati.

Ringkasan

Firecrawl tanpa API key balikin 403 permanen, jadi penulis bikin web-direct.py, skrip 125 baris stdlib dengan rotasi dua lapis: putar key dalam satu provider, lalu pindah ke Tavily. Subcommand health ngecek semua key sekaligus biar kuota habis ketahuan sebelum dipakai. Untuk domain yang dibelokkan ISP, verifikasi lewat Cloudflare DoH dulu, lalu paksa curl ke IP benar dengan --resolve.

Skrip Riset yang Belajar dari Kegagalan API Sendiri

`web_search returned status: 403 for url: https://api.firecrawl.dev/v1/search`

Baris merah itu muncul di terminal VS Code pas saya lagi riset EYD V. Bukan pertama kali, dan emang bukan bug sesaat: Firecrawl tanpa API key balikin 403 permanen [5].

Jadi saya berhenti ngandelin jalur itu dan bikin `web-direct.py` saja.

Rotasi dua lapis, bukan satu kunci sakti

Awalnya saya kira masalahnya cuma satu key kurang. Tapi begitu skripnya jadi dan saya isi `FIRECRAWL_API_KEYS` serta `TAVILY_API_KEYS` dengan beberapa key sekaligus (dipisah koma di file env), kelihatan bahwa limit datang dari dua arah. Error 429 dengan pesan excessive requests artinya request terbanyak dalam waktu singkat [6]. Error 432 artinya kuota plan udah habis; key mana pun yang diputar tetap mentok kalau semua key ada di plan yang sama [6].

Karena itu rotasinya dua lapis: puter key dalam satu provider dulu, dan kalau semuanya kehabisan, baru pindah provider. Firecrawl jadi jalur utama, Tavily sebagai fallback. Skripnya cuma 125 baris Python stdlib, empat subcommand: `search`, `scrape`, `extract`, dan `health`. Subcommand `health` itu kuncinya: dia ngecek semua key di dua ring sekalian, jadi saya nggak baru sadar kuota habis pas lagi butuh jawaban cepat.

Harga pencariannya juga murah, dua credits per sepuluh hasil pencarian Firecrawl [5], jadi lima key free tier aja udah kebanyakan buat riset harian.

DNS yang dibelokkan ISP

Masalah kedua muncul waktu saya mau buka `ejaan.kemdikbud.go.id`, sumber resmi EYD V. Domain itu nggak pernah resolve. Dugaan pertama saya: domain mati. Ternyata kementeriannya aja udah ganti nama, dan domain resminya sekarang `ejaan.kemendikdasmen.go.id`. ISP saya masih menterjemahkan sebagian domain go.id ke IP yang salah, klasik DNS poisoning.

Cara akhirnya dua langkah, dua-duanya lewat terminal. Pertama, tanya DNS langsung ke Cloudflare DoH yang jalannya di atas port 443, sama kayak trafik HTTPS biasa [7], pakai header `Accept: application/dns-json` [8]. Kalau jawabannya `Status: 3`, itu NXDOMAIN: domainnya beneran nggak terdaftar, bukan dibelokkan [8]. Kedua, kalau domain valid tapi resolve lokal tetap salah, paksa curl jalan ke IP yang benar dengan `curl --resolve host:443:IP`. Dokumen curl nyebut opsi ini semacam alternatif /etc/hosts di command line [9].

Kombinasi kecil ini yang selama ini hilang dari stack riset saya: verifikasi DNS dari luar jalur ISP dulu, baru menyalahkan domainnya.

Kenapa pola ini yang menang

Rate limit dan kuota itu keadaan normal API gratisan, bukan anomali yang harus dihindari dengan doa. Yang bikin skrip riset tahan lama bukan kecerdasannya, tapi sifatnya: key diputar otomatis, provider digantor, dan kesehatan semua key bisa dicek sekali jalan. Trafik riset jadi pindah dari jalur yang bisa 403 kapan saja ke jalur yang saya pegang sendiri.

Polanya juga nempel ke tooling lain yang saya punya. Stack riset artikel berbasis AI agent skills yang saya pakai tiap siklus tetap jalan karena prinsip yang sama: punya jalur utama, punya fallback, dan jangan percaya satu titik gagal. Skrip riset ini tambalan di ujung terminalnya.

Sumber:

Artikel terkait