API JSON tersembunyi situs: cara menemukan endpoint (2026)

Parser menarik 400 KB HTML untuk delapan field yang situs berikan dalam respon JSON sebesar 8 KB. Perbedaan lima puluh kali lipat — ini bukan tentang "kode yang indah", ini tentang biaya untuk proxy residensial, di mana Anda membayar untuk setiap gigabyte. Mari kita bahas cara menemukan API internal situs, apa yang menghalangi untuk mengulangnya pada tahun 2026, dan kapan sebaiknya Anda meninggalkan ide ini.

Mengapa mencari API tersembunyi jika HTML sudah diparsing

Hampir setiap antarmuka modern — React, Vue, Angular, Next.js — pertama-tama memuat kerangka halaman, dan data diambil melalui permintaan terpisah ke endpoint mereka sendiri. Endpoint ini tidak terdokumentasi, tetapi mereka ada, memberikan respon dalam JSON yang bersih dan dapat diakses tanpa browser headless.

Apa yang Anda dapatkan dengan beralih ke mereka:

Lalu lintas menurun secara signifikan. Dalam analisis hasil produk yang khas, halaman HTML memiliki berat sekitar 400 KB bersama dengan markup, gaya, dan pelacak, sedangkan endpoint JSON yang sesuai hanya sekitar 8 KB, dan field di dalamnya lebih banyak: ID internal, stok, variasi produk.
Tidak perlu browser. Rendering JavaScript dihilangkan, bersama dengan memori, prosesor, dan puluhan permintaan tambahan untuk font dan analitik.
Data sudah terstruktur. Tidak ada pemilih yang rusak karena perubahan kelas CSS.
Lebih sedikit permintaan — lebih sedikit alasan untuk diblokir. Menggambar satu halaman katalog di browser melibatkan puluhan permintaan ke situs; volume data yang sama melalui API — hanya satu.

Untuk proyek dengan proxy residensial, ini adalah penghematan langsung: tarif dihitung berdasarkan gigabyte, dan beralih dari rendering ke JSON biasanya mengurangi biaya lebih banyak daripada trik apapun dengan pemblokiran gambar. Topik terkait — cara mengurangi lalu lintas parser hingga 5 kali dengan metode lainnya.

Langkah demi langkah: cara menemukan endpoint

Pertama, periksa apakah ada API resmi. Lihat di /developers, /api, /docs situs target. API publik yang terdokumentasi memiliki versi dan memberi peringatan tentang deprekasi — API privat berubah tanpa pemberitahuan.
Buka DevTools (F12) dan pergi ke tab Network, pastikan perekaman diaktifkan.
Aktifkan filter Fetch/XHR. Ini memfilter gambar, font, dan analitik, hanya menyisakan permintaan untuk data.
Bersihkan daftar, untuk menghilangkan kebisingan dari pemuatan awal.
Provokasi data yang diperlukan: gulir hasil, klik "halaman berikutnya", terapkan filter, buka kartu. Permintaan yang Anda minati akan muncul saat tindakan dilakukan.
Temukan respon dengan data Anda. Cara tercepat — Ctrl+F di panel Network: cari nilai unik yang Anda lihat di layar (artikel, harga tepat, bagian nama), dan lihat permintaan mana yang menghasilkan nilai tersebut.
Salin permintaan secara keseluruhan: klik kanan pada baris → Copy → Copy as cURL. Selanjutnya, konversi ke kode melalui curlconverter — dengan cara ini Anda tidak akan kehilangan satu pun header.

Jalur khas yang perlu diperhatikan terlebih dahulu: /api/, /v1/, /v2/, /search, /products, /listings, /graphql.

Kasus khusus: situs di Next.js

Di sini data sering kali tidak memerlukan permintaan terpisah — mereka ada langsung di HTML. Di Pages Router lama, ini adalah blok __NEXT_DATA__. Di App Router (Next.js 13 dan lebih baru), data untuk hidrasi tersebar di panggilan self.__next_f.push() di beberapa node script — ini adalah payload yang diserialisasi dari React Server Components. Menguraikannya secara manual tidak menyenangkan: chunk saling merujuk satu sama lain melalui prefix $ dan dapat terputus di tengah string. Untuk Python, ada pustaka nextflight, yang mem-parsing baik Flight-payload dari HTML, maupun respon RSC mentah (permintaan dengan header RSC: 1), dan menyarankan pencarian berdasarkan nama kunci, bukan indeks array — dengan cara ini parser dapat bertahan saat situs dideploy ulang.

Reverse parameter: pagination dan filter

Endpoint yang ditemukan hampir selalu terparameter. Ada tiga skema yang umum:

Berdasarkan halaman: ?page=3&per_page=20
Offset dan limit: ?offset=40&limit=20
Kursor: ?after=<token>&limit=20 — token halaman berikutnya datang dalam body respon sebelumnya

Tiga aturan yang menghemat jam debugging:

Berhentilah pada paket kosong, bukan pada jumlah halaman yang dihitung sebelumnya: penghitung total di API privat sering kali tidak akurat.
Periksa ukuran paket yang sebenarnya. Meminta 100, yang datang hanya 20 — berarti endpoint memiliki batasan sendiri, dan aritmatika halaman Anda sudah salah.
Jangan masuk ke halaman 500. Pagination yang dalam hampir selalu dipotong oleh server; sebagai gantinya, potong pengambilan dengan filter — berdasarkan kategori, rentang harga, atau tanggal.

Mengapa cURL dari browser berfungsi, tetapi kode Anda tidak

Ini adalah titik kegagalan yang paling umum, dan penyebabnya hampir selalu sama: header yang hilang. cURL yang disalin membawa seluruh konteks permintaan, sedangkan klien yang ditulis sendiri tidak.

Apa yang biasanya menjadi wajib:

Header kustom dengan prefix X- — X-CSRF-Token, X-Requested-With: XMLHttpRequest, dan berbagai X-*-Token yang disisipkan oleh frontend. Tanpa mereka, Anda akan mendapatkan respon dalam rentang 400–500.
Referer — header kontekstual yang dihasilkan oleh tindakan pengguna. Banyak endpoint memeriksa bahwa permintaan "datang dari halaman mereka sendiri".
Authorization: Bearer <JWT> — token yang memiliki masa hidup pendek, biasanya 15–60 menit. Menghardcode-nya tidak ada gunanya: Anda perlu bisa mendapatkan yang baru.
Cookie sesi — simpan dalam objek sesi, bukan salin secara manual.
Content-Type yang benar untuk POST: application/json dan application/x-www-form-urlencoded mengkodekan body dengan cara yang berbeda, dan ketidakcocokan dengan tipe yang dinyatakan akan merusak permintaan tanpa memberi tahu.

Di mana mencari token itu sendiri, jika tidak ada di cookie: di sumber HTML dalam <script> (cari nilai yang diketahui melalui Ctrl+F), di bundel JavaScript, di localStorage atau IndexedDB — tab Aplikasi di DevTools.

Perangkap yang baru diketahui terlambat

API privat berubah tanpa pemberitahuan. Tidak ada versi, janji kompatibilitas, dan dukungan: tim frontend mengganti nama field pada Kamis malam, dan parser Anda mengumpulkan kekosongan. Perlindungan — bukan "pemilih yang andal", tetapi kontrol struktur: periksa bahwa field yang wajib ada dan dalam tipe yang benar; awasi proporsi nilai kosong dan jumlah catatan dalam pengujian; lewati catatan yang rusak, tetapi beri peringatan jika cacat melebihi 10%; simpan respon mentah untuk perbandingan di kemudian hari.

API kadang-kadang dilindungi lebih ketat daripada halaman. Ini sering terjadi: HTML diberikan dengan tenang, tetapi di /api/ ada anti-bot yang memeriksa baik sidik jari TLS maupun kombinasi header. Dalam hal ini, penghematan lalu lintas berubah menjadi peningkatan proporsi permintaan yang tidak berhasil, dan keuntungan hilang.

Permintaan yang ditandatangani. Jika di parameter terlihat sesuatu seperti sign, hash, atau _s, frontend menghitung tanda tangan dalam JavaScript. Menciptakannya kembali adalah proyek tersendiri, dan sering kali lebih murah untuk tetap di HTML.

Pembatasan frekuensi. Endpoint privat tidak dirancang untuk aliran: jaga 1–2 permintaan per detik, tetapkan timeout terpisah untuk koneksi dan pembacaan (misalnya, 5 dan 30 detik), ulangi hanya kesalahan transien — 429, 500, 502, 503, 504 — dan jangan sentuh 401 dan 404. Penundaan eksponensial dengan jitter adalah suatu keharusan, jika tidak, semua pekerja akan memulai putaran kedua secara bersamaan. Lebih lanjut — dalam analisis timeout dan logika retry untuk proxy.

Kerangka hukum. Endpoint publik yang tidak terautentikasi — satu situasi, masuk ke akun — prinsip yang sama sekali berbeda: pendaftaran berarti menerima perjanjian pengguna. Data pribadi termasuk dalam GDPR terlepas dari seberapa mudah mereka diakses. Fakta — harga, karakteristik, ketersediaan — tidak dilindungi oleh hak cipta, berbeda dengan teks dan gambar.

Kapan tetap di HTML

API tersembunyi — tidak selalu menguntungkan. Tetaplah pada analisis halaman jika:

situs bersifat server dan tidak ada API internal sama sekali;
endpoint memerlukan tanda tangan atau rotasi token — memeliharanya lebih mahal daripada halaman;
API memiliki perlindungan yang lebih ketat daripada halaman publik;
Anda memerlukan hasil akhir yang dikumpulkan frontend dari beberapa sumber;
Anda mengelola puluhan situs: satu jalur HTML lebih mudah diskalakan daripada kebun binatang API privat dengan keunikan masing-masing.

Jenis proxy apa yang diambil untuk parsing API

Berpindah ke JSON mengubah perhitungan, karena titik sempit bergeser: lalu lintas menjadi sedikit, tetapi tuntutan terhadap kualitas IP dan stabilitas sesi meningkat.

Endpoint terbuka tanpa otorisasi dan tanpa anti-bot. Di sini cukup menggunakan proxy data center: volume data kecil, tidak perlu membayar untuk residensial.
Endpoint di belakang anti-bot atau terkait dengan sesi. Diperlukan proxy residensial dengan sesi lengket: token, cookie, dan IP harus cocok sepanjang rantai, jika tidak server akan membatalkan sesi pada permintaan kedua. Pada saat yang sama, biaya tetap rendah — gigabyte dalam mode JSON digunakan dengan lambat.
Data dari aplikasi seluler. Jika versi web ditutup, dan aplikasi memberikan hal yang sama dengan lebih mudah, endpoint dicari melalui intersepsi lalu lintas — ini adalah prosedur terpisah, dibahas dalam artikel tentang mencari API tersembunyi aplikasi seluler melalui mitmproxy.

Singkatnya

Dua puluh menit di DevTools sering menggantikan hari-hari perjuangan dengan browser headless: filter Fetch/XHR, pencarian berdasarkan nilai yang terlihat, Copy as cURL — dan Anda memiliki permintaan yang berfungsi di tangan. Selanjutnya, detailnya yang harus dipecahkan: memindahkan semua header, menganalisis skema pagination, menempatkan validasi respon, dan menilai dengan jujur, apakah endpoint lebih terlindungi daripada halaman itu sendiri. Di mana API privat berfungsi, ia mengurangi baik volume lalu lintas maupun jumlah permintaan — yaitu, sekaligus mengurangi biaya proxy dan kemungkinan pemblokiran.