[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-rate-limit::tr":3,"gloss-cluster-rate-limit::tr":23,"gloss-next-rate-limit::tr":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"rate-limit","no-code","Hız Sınırı (Rate Limit)","Hız sınırı, bir API sağlayıcısının tek bir uygulamanın, API anahtarının veya kullanıcının belirli bir zaman aralığında yapabileceği istek sayısına koyduğu bir kısıtlamadır — örneğin \"dakikada 100 istek\" veya \"günde 10.000 istek\" — sağlayıcının altyapısını aşırı yüklenmeden korumak, kötüye kullanımı önlemek ve (ücretli API'ler için) plan katmanı fiyatlandırma sınırlarını uygulamak için tasarlanmıştır. No-code geliştiriciler için özellikle neden önemli: hız sınırları, \"otomasyonum rastgele çalışmayı bıraktı\" hatalarının en yaygın nedenlerinden biridir, çünkü düşük hacimde sorunsuz çalışan bir iş akışı (günde 10 otomasyon), kullanım ölçeklendikçe (günde 10.000 otomasyon aniden bir sağlayıcının günlük 5.000 sınırına çarptığında) sessizce başarısız olmaya başlayabilir; ve bu başarısızlık, geliştirici özellikle bir 429 durum kodunu kontrol etmedikçe genellikle net bir \"sınırınızı aştınız\" mesajından ziyade aralıklı, teşhisi zor hatalar gibi görünür. Hız sınırlarını anlamak, toplu veri işleyen otomasyonlar tasarlarken de gereklidir — her biri ayrı bir API çağrısını tetikleyen 50.000 e-tablo satırı üzerinde bir otomasyonu döngüye sokmak, iş akışı kasıtlı bir hız sınırlama veya toplu işleme içermedikçe neredeyse her zaman yolun ortasında bir hız sınırına çarpar. Nasıl çalışır: API'ler tipik olarak hız sınırı durumunu yanıt başlıkları aracılığıyla iletir (örneğin, `X-RateLimit-Limit: 100`, `X-RateLimit-Remaining: 23`, `X-RateLimit-Reset: 1719856800`); bu sayede iyi oluşturulmuş bir istemci duvara çarpmadan önce proaktif olarak yavaşlayabilir ve sınır gerçekten aşıldığında bir HTTP 429 \"Too Many Requests\" durum kodu döndürür, genellikle tekrar denemeden önce ne kadar beklenmesi gerektiğini gösteren bir `Retry-After` başlığıyla birlikte. Somut örnek — dakikada 60 istekle sınırlı üçüncü taraf bir veri API'si aracılığıyla 2.000 lead'i zenginleştiren bir Make senaryosunda bir hız sınırını ele almak: 2.000 isteğin tümünü mümkün olduğunca hızlı ateşlemek yerine (ilk dakikadan sonra kesinlikle 429 hataları tetikler), geliştirici her 50 kayıtlık grubun ardından bir \"Sleep\" modülü ekler — devam etmeden önce senaryoyu hesaplanmış bir gecikme için duraklatır — ve her API çağrısını özellikle bir 429 yanıtını yakalayan, `Retry-After` başlığını okuyan, o kadar bekleyen ve ardından tüm çalıştırmayı başarısız kılmak yerine aynı isteği yeniden deneyen bir hata işleyiciye sarar. Yüksek hacimli API çağrılarıyla uğraşan üretim düzeyi no-code otomasyonlar, otomasyon üretimde başarısız olmaya başladıktan sonra sadece işleme eklemek yerine (toplu işleme, hız sınırlama, geri çekilmeli yeniden deneme) her zaman hız sınırlarına karşı savunmacı bir şekilde tasarlanmalıdır. Bazı API'ler ayrıca sürekli hız sınırlarından ayrı patlama sınırlarını da uygular (örneğin, \"saniyede 10 istek, günde 1.000'e kadar\") — her iki tavana çarpmak da aynı 429 yanıtını üretir, bu yüzden sağlam bir otomasyon tek bir sabit eşiği varsaymak yerine yanıt başlıklarını kontrol eder.","Hız sınırı, bir uygulamanın belirli bir sürede yapabileceği API isteği sayısına konan üst sınırdır; sağlayıcının sunucularını aşırı yükten korur.",null,[11,14,17,20],{"slug":12,"name":13},"api","API",{"slug":15,"name":16},"api-key","API Anahtarı (API Key)",{"slug":18,"name":19},"polling","Yoklama (Polling)",{"slug":21,"name":22},"webhook","Webhook",[24,28,32,35,36,37,40,43,46,49,52,55],{"slug":25,"category":5,"name":26,"updated_at":27},"action","Eylem (Action)","2026-08-24T02:46:36+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"aggregator","Aggregator (Toplayıcı)","2026-08-24T02:46:37+00:00",{"slug":33,"category":5,"name":34,"updated_at":27},"airtable","Airtable",{"slug":12,"category":5,"name":13,"updated_at":27},{"slug":15,"category":5,"name":16,"updated_at":27},{"slug":38,"category":5,"name":39,"updated_at":31},"approval-workflow","Onay İş Akışı (Approval Workflow)",{"slug":41,"category":5,"name":42,"updated_at":27},"automation-platform","Otomasyon Platformu (Automation Platform)",{"slug":44,"category":5,"name":45,"updated_at":27},"automation-recipe","Otomasyon Tarifi (Automation Recipe)",{"slug":47,"category":5,"name":48,"updated_at":27},"backend-as-a-service","Hizmet Olarak Backend (BaaS)",{"slug":50,"category":5,"name":51,"updated_at":31},"backfill","Geriye Dönük Doldurma (Backfill)",{"slug":53,"category":5,"name":54,"updated_at":27},"bubble","Bubble",{"slug":56,"category":5,"name":57,"updated_at":27},"business-logic","İş Mantığı (Business Logic)"]