Apa Itu Rate Limit API? Penyebab HTTP 429 dan Cara Menanganinya

Kamu menjalankan script API dan awalnya semua request mendapatkan status 200. Setelah beberapa ratus request, server mulai membalas 429 Too Many Requests. Ditunggu beberapa saat, request kembali normal. Kondisi seperti ini biasanya berarti kamu sedang berhadapan dengan rate limit.

Rate limit merupakan mekanisme yang digunakan server untuk membatasi berapa banyak request yang boleh dilakukan client dalam periode tertentu. Tujuannya bukan cuma mencegah serangan. Rate limiting juga membantu menjaga kapasitas server, membagi resource secara lebih adil, mengontrol penggunaan API, dan mencegah satu client menghabiskan seluruh kapasitas layanan.

Yang sering salah dipahami adalah rate limit dianggap selalu berdasarkan IP. Padahal sebuah API bisa membatasi berdasarkan API key, akun, user ID, endpoint, cookie, organization, token, bahkan kombinasi beberapa sinyal sekaligus.

Karena itu kalau mendapatkan 429, solusi yang benar bukan otomatis mengganti IP. Client sebaiknya membaca aturan API, melihat response header, mengurangi request rate, menerapkan queue, retry yang terbatas, dan menghormati Retry-After jika tersedia.

Kalau belum familiar dengan arti 429, baca juga artikel Mengenal HTTP Status Code.

Apa Itu Rate Limit?

Rate limit adalah aturan yang membatasi jumlah operasi atau request dalam jangka waktu tertentu.

Contohnya sebuah API mempunyai aturan:

Artinya client hanya diperbolehkan membuat sejumlah request tertentu di dalam window tersebut.

Jika request terlalu banyak, server dapat:

• mengembalikan HTTP 429,
• menunda request,
• menolak request tertentu,
• mengurangi throughput,
• atau pada kondisi tertentu memutus koneksi.

Kenapa API Membutuhkan Rate Limit?

Bayangkan server API memiliki kapasitas menangani satu juta request per menit.

Tanpa rate limit, satu client yang salah konfigurasi bisa saja mengirim:

sendirian.

Akibatnya pengguna lain ikut terkena dampak.

Rate limit membantu mengatur distribusi resource.

Fungsi Rate Limiting

Rate limiting bisa digunakan untuk berbagai tujuan:

• melindungi server dari overload,
• mengurangi abuse,
• membatasi penggunaan berdasarkan paket layanan,
• mencegah request tidak sengaja dalam jumlah besar,
• mengurangi brute-force attempt,
• membagi kapasitas API antarclient,
• menjaga database dan backend dependency tetap stabil.

Apa Arti HTTP 429 Too Many Requests?

429 Too Many Requests menunjukkan bahwa client mengirim terlalu banyak request dalam periode tertentu.

Contoh response:

Status ini didefinisikan dalam RFC 6585.

Server juga dapat memberikan penjelasan lebih lanjut melalui response body atau response header.

Referensi teknisnya dapat dibaca di RFC 6585 — Additional HTTP Status Codes.

Apa Itu Retry-After?

Retry-After adalah response header yang memberi informasi kapan client sebaiknya mencoba request lagi.

Contoh:

Artinya client diminta menunggu sekitar 60 detik sebelum melakukan request berikutnya.

Nilainya juga dapat diberikan dalam bentuk tanggal HTTP.

Kenapa Retry-After Harus Dihormati?

Kalau server sudah memberitahu client untuk berhenti selama 60 detik tetapi script malah terus mengirim request setiap 100 milidetik, server akan terus menerima traffic yang sebenarnya sudah diminta berhenti.

Hal ini bisa:

• memperpanjang rate limiting,
• meningkatkan error,
• membebani server,
• membuat integration diblokir,
• atau memicu policy abuse.

Karena itu client yang baik harus bisa melakukan pause.

Rate Limit Tidak Selalu Berdasarkan IP

Ini salah satu konsep terpenting.

RFC 6585 tidak mewajibkan server menggunakan IP untuk menentukan client.

Server bisa menghitung berdasarkan:

• IP address,
• API key,
• access token,
• akun,
• session,
• cookie,
• endpoint,
• organization,
• resource tertentu.

Jadi mengganti IP belum tentu mereset rate limit.

Contoh Rate Limit Berdasarkan IP

Misalnya:

Semua request dari IP tersebut menggunakan counter yang sama.

Rate Limit Berdasarkan API Key

API juga bisa menggunakan credential sebagai identitas.

Kalau API key yang sama digunakan dari lima server berbeda, request tetap dapat masuk ke counter yang sama.

Rate Limit Berdasarkan User

Layanan yang mempunyai akun dapat menghitung request berdasarkan user ID.

Contohnya:

Dengan desain seperti ini, perubahan alamat IP tidak mengubah quota akun.

Rate Limit Bisa Berbeda per Endpoint

Tidak semua endpoint harus mempunyai batas yang sama.

Contohnya:

Endpoint login biasanya membutuhkan pembatasan lebih ketat daripada endpoint read-only biasa.

Apa Itu Rate Limit Window?

Window adalah periode waktu yang digunakan untuk menghitung request.

Contohnya:

Artinya server mempunyai window 60 detik.

Ada beberapa algoritma berbeda untuk menerapkan window tersebut.

Fixed Window Rate Limiting

Fixed window membagi waktu menjadi blok tetap.

Contohnya:

Implementasinya sederhana, tetapi ada edge case di batas window.

Client bisa mengirim banyak request pada:

kemudian kembali mengirim banyak request pada:

sehingga secara waktu nyata terjadi burst cukup besar.

Sliding Window

Sliding window menghitung request berdasarkan rentang waktu yang bergerak bersama waktu saat ini.

Misalnya pada pukul:

server menghitung request dari:

Pendekatan ini membuat limit lebih halus daripada fixed boundary.

Token Bucket

Token bucket membayangkan client mempunyai sejumlah token.

Setiap request memakai token.

Token kemudian diisi kembali berdasarkan rate tertentu.

Metode ini memungkinkan burst kecil selama bucket masih mempunyai token tanpa membiarkan request berjalan tanpa batas.

Leaky Bucket

Leaky bucket sering dibayangkan seperti antrean yang mengeluarkan request dengan kecepatan terkontrol.

Request masuk ke queue, kemudian diproses dengan rate tertentu.

Pendekatan seperti ini membantu meratakan burst traffic.

Rate Limiting vs Throttling

Kedua istilah sering dipakai bergantian, tetapi secara konsep bisa dibedakan.

Implementasi nyata bisa menggunakan kombinasi keduanya.

Rate Limit vs Quota

Rate limit biasanya fokus pada frekuensi.

Quota lebih sering berarti total pemakaian dalam periode lebih panjang.

Contoh:

Bagaimana Tahu API Hampir Mencapai Limit?

Banyak API memberikan informasi melalui response header.

Formatnya tidak standar untuk semua API, tetapi contoh yang sering ditemui:

Artinya kurang lebih:

Contoh Rate Limit Header GitHub API

GitHub REST API menggunakan header seperti:

Client bisa memakai informasi tersebut untuk mengatur pace request sebelum benar-benar terkena limit.

Jangan Menunggu Sampai Remaining = 0

Kalau aplikasi mengetahui sisa quota, jauh lebih baik mulai memperlambat request lebih awal.

Contoh:

Dengan pola seperti ini, aplikasi lebih stabil dibanding terus mengirim request sampai ditolak.

Apa Hubungan Proxy dengan Rate Limit?

Proxy mengubah jalur koneksi dan dapat membuat server tujuan melihat IP proxy sebagai source IP.

Kalau sebuah layanan melakukan rate limit murni berdasarkan IP, maka setiap exit IP dapat mempunyai counter berbeda sesuai implementasi server.

Tetapi jangan langsung menyimpulkan bahwa proxy merupakan solusi untuk melewati limit.

Server bisa membatasi berdasarkan:

• akun,
• API key,
• token,
• session,
• cookie,
• organization,
• IP,
• kombinasi beberapa identifier.

Kenapa Mengganti Proxy Belum Tentu Menghilangkan 429?

Misalnya rate limit berdasarkan API key:

Request melalui:

tetap memakai:

maka server bisa tetap menghitung semuanya sebagai satu quota.

Rotasi IP Bukan Pengganti Rate Control

Kalau penyedia API mengatakan:

client sebaiknya mengatur aplikasi supaya tetap berada di batas tersebut.

Menggunakan banyak IP untuk menghindari pembatasan yang sengaja diterapkan service bisa melanggar Terms of Service dan berujung pada pemblokiran integrasi.

Proxy lebih cocok digunakan untuk kebutuhan seperti:

• network testing,
• geo testing,
• monitoring endpoint dari lokasi berbeda,
• memisahkan traffic aplikasi,
• testing konfigurasi jaringan.

Kenapa Concurrency Bisa Memicu Rate Limit?

Bayangkan limit API:

Aplikasi mempunyai 100 worker dan semuanya mengirim request bersamaan.

Walaupun script hanya berjalan beberapa detik, burst-nya sudah melewati kapasitas yang diizinkan.

Gunakan Queue untuk Mengontrol Request

Daripada seluruh worker menembak API sekaligus, gunakan queue.

Concurrency menjadi lebih terkontrol dan traffic lebih mudah diprediksi.

Apa Itu Exponential Backoff?

Exponential backoff membuat jeda retry bertambah setiap kali terjadi kegagalan.

Contoh:

Tujuannya mencegah client terus membanjiri server yang sedang meminta traffic dikurangi.

Kenapa Perlu Jitter?

Bayangkan 10.000 client terkena 429 pada saat yang sama.

Kalau semuanya retry tepat setelah 60 detik:

server bisa terkena traffic spike baru.

Jitter menambahkan sedikit variasi acak pada waktu tunggu.

Contohnya:

Traffic menjadi lebih tersebar.

Contoh Retry yang Buruk

Kalau API sedang rate limited, loop seperti ini bisa terus menghasilkan error tanpa henti.

Contoh Pola Retry yang Lebih Sehat

Selalu berikan maksimum retry.

Contoh Rate Limit Handling dengan Python

Contoh tersebut sengaja dibatasi lima percobaan sehingga script tidak retry tanpa batas.

Handling 429 di JavaScript

Retry-After Bisa Berupa Tanggal

Jangan menganggap nilainya selalu angka detik.

Header dapat berbentuk:

atau:

HTTP client production sebaiknya mampu memahami kedua bentuk kalau API memang menggunakannya.

Apakah Semua 429 Punya Retry-After?

Tidak.

RFC mengizinkan server menyertakan Retry-After, tetapi header tersebut tidak wajib selalu ada.

Kalau tidak tersedia, client bisa mengikuti dokumentasi API atau memakai backoff yang wajar.

Rate Limit Header Tidak Selalu Sama

Setiap provider bisa mempunyai format sendiri.

Contoh:

API lain mungkin memakai nama berbeda atau mengikuti standar header yang berbeda.

Karena itu jangan membuat client berdasarkan asumsi tanpa membaca dokumentasi API.

Primary dan Secondary Rate Limit

Sebuah layanan bisa mempunyai lebih dari satu jenis limit.

GitHub, misalnya, membedakan primary rate limit dan secondary rate limit.

Primary limit berhubungan dengan quota request utama.

Secondary limit dapat digunakan untuk membatasi pola penggunaan tertentu yang terlalu agresif, misalnya concurrency atau aktivitas yang dianggap berlebihan.

Jadi kondisi:

bisa terjadi pada API yang mempunyai mekanisme pembatas tambahan.

Kenapa Authenticated Request Bisa Punya Limit Berbeda?

API dapat memberikan quota berbeda berdasarkan apakah request mempunyai identitas yang jelas.

Contohnya:

GitHub merupakan salah satu API yang memberikan batas lebih tinggi pada banyak authenticated request dibanding request anonymous.

Gunakan Caching untuk Mengurangi Request

Salah satu cara terbaik mengurangi rate limit adalah jangan meminta data yang sama berulang kali kalau memang tidak perlu.

Misalnya API response valid selama lima menit.

Daripada:

gunakan:

Conditional Request juga Bisa Membantu

HTTP mempunyai mekanisme seperti ETag dan conditional request.

Contoh:

Kalau data belum berubah, server dapat merespons:

Beberapa API bahkan memberikan perlakuan rate limit yang lebih efisien untuk conditional request.

Polling Terlalu Sering Adalah Sumber Masalah Umum

Misalnya status job hanya berubah setiap beberapa menit, tetapi aplikasi melakukan polling:

Itu berarti:

Padahal polling setiap 5 detik mungkin sudah cukup.

Gunakan Webhook Kalau Tersedia

Kalau provider API menyediakan webhook, aplikasi tidak perlu terus bertanya apakah sesuatu sudah berubah.

Polling:

Webhook:

Untuk event-driven workflow, webhook bisa jauh lebih efisien.

Batch Request Lebih Efisien Jika API Mendukung

Daripada:

API tertentu mungkin menyediakan:

Satu request bisa menggantikan beberapa request terpisah.

Jangan Mengirim Data yang Tidak Dibutuhkan

Jika API mendukung field selection atau pagination, gunakan secara efisien.

Contohnya daripada mengambil:

kalau hanya membutuhkan:

request lebih kecil dan workload server juga berkurang.

Pagination dan Rate Limit

Pagination bisa membuat request bertambah banyak.

Misalnya API memberikan 100 item per halaman dan ada 10.000 item.

Client perlu menghitung kebutuhan request supaya tidak melewati quota.

Rate Limit di Web Scraping

Website juga dapat menerapkan pembatasan request walaupun tidak mempunyai API publik.

Signal-nya bisa berupa:

• HTTP 429,
• 403,
• challenge page,
• connection slowdown,
• temporary block.

Scraping yang diizinkan tetap sebaiknya mempunyai request pacing dan mengikuti aturan website.

robots.txt dan Rate Limit Apakah Sama?

Tidak.

robots.txt adalah mekanisme yang menyampaikan aturan crawling kepada crawler yang mematuhinya.

Rate limit adalah enforcement mengenai seberapa cepat atau banyak request boleh dilakukan.

429 vs 403 Apa Bedanya?

429 berarti terlalu banyak request.

403 berarti server memahami request tetapi menolak akses.

Tapi sebuah provider bisa menggunakan policy sendiri dan tidak selalu memilih status yang sama.

429 vs 503 Apa Bedanya?

429 Too Many Requests biasanya menunjukkan pembatasan terhadap client.

503 Service Unavailable biasanya menunjukkan server atau service sementara tidak siap menerima request.

Keduanya dapat menggunakan Retry-After.

Apa Itu Retry Storm?

Retry storm terjadi ketika banyak client yang gagal langsung mencoba ulang tanpa koordinasi.

Contohnya server overload menghasilkan 503.

Seribu client langsung retry setiap 100 ms.

Backoff dan jitter membantu memutus siklus tersebut.

Rate Limiting pada Login Endpoint

Endpoint login biasanya perlu perlindungan khusus.

Rate limit bisa diterapkan per:

• IP,
• username,
• account,
• device,
• kombinasi beberapa sinyal.

Kalau hanya per-IP, pengguna di belakang NAT atau CGNAT bisa saling memengaruhi.

NAT, CGNAT, dan Rate Limit per-IP

Beberapa pengguna dapat terlihat datang dari public IP yang sama.

Contohnya:

Kalau sebuah service membatasi secara kasar berdasarkan IP, aktivitas beberapa pengguna bisa masuk ke counter yang sama.

Ini salah satu alasan sistem besar sering memakai lebih dari satu sinyal untuk rate limiting.

Rate Limit pada Server Sendiri

Kalau kamu mengelola API sendiri, rate limiting sebaiknya dilakukan pada layer yang tepat.

Bisa berada pada:

• application server,
• API gateway,
• reverse proxy,
• CDN,
• WAF,
• load balancer tertentu.

Contoh Rate Limiting dengan Reverse Proxy

Secara arsitektur:

Request berlebihan dapat dihentikan sebelum mencapai backend utama.

Kenapa Rate Limit Perlu Observability?

Tanpa log dan metric, administrator tidak tahu apakah limit terlalu ketat atau terlalu longgar.

Metric yang berguna antara lain:

• request per second,
• jumlah 429,
• top client,
• endpoint paling ramai,
• remaining quota,
• retry frequency,
• latency.

Cara Troubleshooting HTTP 429

1. Baca Response Body

API sering menjelaskan alasan limit.

2. Cek Retry-After

Kalau ada, hormati nilainya.

3. Cek Header Rate Limit

Cari informasi seperti:

4. Baca Dokumentasi API

Jangan menebak algoritma rate limit.

5. Kurangi Concurrency

Batasi jumlah worker aktif.

6. Gunakan Queue

Atur traffic supaya lebih stabil.

7. Terapkan Backoff

Hindari retry agresif.

8. Cache Data

Jangan mengambil data yang sama berulang kali tanpa alasan.

9. Gunakan Webhook Jika Ada

Kurangi kebutuhan polling.

10. Hentikan Retry Setelah Batas Tertentu

Jangan buat loop retry tak terbatas.

Kesalahan Umum Saat Menangani Rate Limit

• langsung mengganti proxy setiap mendapat 429,
• menganggap semua limit berdasarkan IP,
• mengabaikan Retry-After,
• retry tanpa batas,
• memakai concurrency terlalu tinggi,
• polling terlalu sering,
• tidak membaca rate-limit header,
• tidak menggunakan cache,
• tidak membedakan 429 dan 503,
• menganggap authenticated dan anonymous request selalu punya quota yang sama.

Checklist Client API yang Baik

FAQ Rate Limit API

Apa itu rate limit API?

Rate limit API adalah aturan yang membatasi jumlah request yang boleh dilakukan client dalam jangka waktu atau quota tertentu.

Apa arti HTTP 429?

HTTP 429 Too Many Requests berarti client telah mengirim terlalu banyak request dalam periode tertentu menurut kebijakan server.

Apa fungsi Retry-After?

Retry-After memberi informasi berapa lama client sebaiknya menunggu sebelum mencoba request lagi.

Apakah 429 selalu berdasarkan IP?

Tidak. Rate limit bisa dihitung berdasarkan IP, akun, API key, token, cookie, resource, atau kombinasi beberapa identifier.

Apakah mengganti proxy bisa menghilangkan 429?

Belum tentu. Kalau rate limit berdasarkan API key atau akun, mengganti IP proxy tidak mereset counter. Menggunakan proxy untuk menghindari pembatasan layanan juga bisa melanggar kebijakan layanan.

Apa itu exponential backoff?

Exponential backoff adalah strategi retry dengan waktu tunggu yang bertambah setiap kali percobaan gagal.

Apa fungsi jitter?

Jitter menambahkan variasi pada waktu retry supaya banyak client tidak mencoba kembali pada waktu yang persis sama.

Apa beda rate limit dan quota?

Rate limit biasanya membatasi frekuensi request dalam periode pendek, sedangkan quota membatasi total pemakaian dalam periode lebih panjang.

Apa beda 429 dan 503?

429 biasanya menunjukkan client terlalu banyak request, sedangkan 503 berarti service sementara tidak siap menangani request.

Bagaimana cara menghindari rate limit secara benar?

Kurangi request rate, gunakan cache, queue, batching, webhook bila tersedia, hormati Retry-After, baca header quota, dan ikuti dokumentasi serta kebijakan API.