Haberler ve analiz
API hız sınırları: iş akışları arasında istek bütçesi paylaşmak
Hesap düzeyindeki API sınırlarını akışlar arasında paylaşın, HTTP 429 yanıtını işleyin, önemli işlere öncelik verin ve senkronizasyon gecikmelerini izleyin.
Gece dışa aktarımı görünür hata olmadan biter, ancak çalışanlar ertesi sabah müşteri kayıtlarını güncelleyemez. Nedeni dış API'nin ortak sınırı olabilir: toplu işlem, kullanıcı arayüzü ve idari kontroller aynı kaynağı tüketir. Her akış tek başına ölçülü görünürken toplam trafik izin verilen istek hızını aşar.
API sınırlarını ekibin ortak bütçesi olarak ele alın. Hem istek kotasını hem kapsamını bilin: hesap, uç nokta, anahtar, plan veya başka sınır. Birden fazla çalışanın koordinasyona ihtiyacı olup olmadığını ve kapasitenin nasıl dağıtılacağını bu belirler.
Twilio Content API güncellemesi neyi gösteriyor?
Twilio'nun 30 Eylül 2026 yayını, Content API'nin hesap düzeyindeki sınırlarını ve aşıldığında HTTP 429 yanıtlarını açıklıyor. Değerler işleme göre farklı: Fetch Content saniyede 100, List Content saniyede 20 istek olarak listeleniyor. Update Content de saniyede 20 istek.
Bu sayılar belirtilen Content API uç noktalarına aittir. Voice, Verify, diğer Twilio ürünleri veya başka sağlayıcılara genellenmemelidir. Entegrasyonunuz için işlem, güncel sınır, kapsam ve belge bağlantısını içeren bir kayıt tutun.
Farklı erişim anahtarları mutlaka bağımsız bütçe sağlamaz. Sağlayıcı hesap düzeyinde sayıyorsa birkaç anahtar aynı kotayı paylaşır. Farklı ekipler entegrasyonları yönetirken ve arka plan betikleri müşteri uygulamasından bağımsız çalışırken bu özellikle önemlidir.
İstek hızı ve eşzamanlılık farklı sorunları çözer
Eşzamanlı çalışanları sınırlamak yürütme kapasitesini korur, ancak istek hızını mutlaka sınırlamaz. Bir çalışan art arda çok sayıda kısa istek gönderebilir; birkaç yavaş çalışan aynı aralıkta az trafik üretebilir. Sağlayıcı sınırındaki gerçek giden akışı ölçün.
n8n hız sınırlama rehberi, kuyruk modu ve eşzamanlılık kontrollerinin üçüncü taraf API sınırlarını kaldırmadığını açıkça anlatır. Giden isteklerin temposunu gelen trafik korumasından da ayırır: böyle kontrol gerektiğinde genel webhook ayrı sınırlama katmanı ister.
İş akışı otomasyonunda önce kıt kaynağı belirleyin. Yürütme kuyruğu, sağlayıcının API sınırı ve müşteri görevinin son tarihi farklı mekanizmalar gerektirebilir. Çalışan eklemek yalnızca mevcut kotayı daha hızlı tüketebilir.
Kapasiteyi operasyonel ihtiyaçlara göre dağıtın
Bir mağazanın mesaj şablonlarını güncellediğini, durumlarını operatöre gösterdiğini ve aynı anda tüm katalog mutabakatını yürüttüğünü düşünün. Bu bir tasarım örneğidir, belirli uygulamadan ölçüm değildir. İşlemlerin aciliyeti farklıdır: etkileşimli istek büyük idari dışa aktarımın arkasında süresiz beklememelidir.
Trafiği sınıflara ayırın: etkileşimli işlemler, zorunlu senkronizasyon ve toplu işleme. Her biri için kabul edilebilir gecikmeyi, ertelenebilirliği ve süre aşımının sonuçlarını tanımlayın. Önemli işlemlere kapasite ayırın, ardından toplu işlerin boş kapasiteyi nasıl kullanacağını belirtin.
Birden fazla süreçte bütçe hesabı koordine edilmelidir. Her betikte yerel bekleme tek örnekte çalışabilir, ancak ölçeklemeden sonra toplam yükü yansıtmayabilir. Ortak dağıtıcı veya koordineli sayaç deposu olası uygulama seçenekleridir. Seçim mimariye ve hata yönetimi gereksinimlerine bağlıdır.
Yayımlanan tavanda sürekli çalışmayı hedeflemeyin. Kısa sıçramalar, idari çağrılar ve değişen yanıt süreleri değişkenlik yaratır. Rezervi evrensel yüzde yerine gözlemlere ve gecikmenin sonuçlarına göre seçin.
HTTP 429'u zamanlanmış görev olarak işleyin
Görevi koruyun ve ne zaman yeniden denenebileceğini belirleyin. Yanıt Retry-After içeriyorsa sağlayıcı sözleşmesine göre yorumlayın. n8n beklemeyi, gruplamayı ve denemeler arasındaki süreyi artırmayı anlatır. Bunlar davranışı ayarlama araçlarıdır; her akışın sağlayıcı sınırlarına otomatik uyacağı vaadi değildir.
Açık yeniden deneme zamanı yoksa çalışanların aynı anda başlamaması için küçük rastgele dağılım içeren sınırlı bekleme politikası düşünün. Politikaya son nokta belirleyin: görev süresi, deneme sayısı veya operatöre devir. Teknik olarak yeniden denemek mümkün olsa bile eskimiş işlemi süresiz tekrarlamanın değeri azdır.
Okuma ve yazma isteklerinin sonuçları farklıdır. Yazmayı yinelemeden önce işlemin zaten gerçekleşmiş olup olmadığını belirleyin. Ortak bütçe yönetimi, yinelenen sonuca karşı korumanın yerini almaz; bu API entegrasyon sözleşmesinin ayrı parçasıdır.
Yararlı güncelliği koruyarak trafiği azaltın
Çalışan eklemeden önce API'nin sayfalı alım, toplu işlemler veya yavaş değişen referans verisinin yerel saklanmasını destekleyip desteklemediğini kontrol edin. Önbellek güncelleme kuralı ister: dünkü personel listesi rapor için kabul edilebilir, erişim kararı için yetersiz olabilir.
Özel API açıklaması, önbelleği ve istek sınırlarını mimari öğeler olarak ele alır. Yararlı bağlamdır, ölçülmüş kapasitenin kanıtı değildir. Yeni akışın yine kendi güncellik gereksinimlerine ve kaynak değişikliği yönetimine ihtiyacı vardır.
Kuyruk yaşını, işlem bazında 429 sayılarını, acil görev payını ve toplu çalışmadan sonraki toparlanma süresini izleyin. Günler süren senkronizasyon birikimi yanında düşük hata sayısı, entegrasyonun kabul edilebilir çalıştığını göstermez. İzleme, yararlı sonucu teslim etmek için gereken zamanı yansıtmalıdır.
Ölçeklemeden önce birleşik yükü test edin
Uygun ortamda canlı arayüzü, planlanan dışa aktarımı ve idari kontrolleri birlikte çalıştırın. 429'un görünür görev bıraktığını, öncelikli işlemlere kapasite kaldığını ve biriken kuyruğun sonunda küçüldüğünü doğrulayın. Olay sırasında öncelikleri kimin değiştirebileceğini kaydedin.
Hacmi artırmadan API sözleşmesini ve sürümünü de kontrol edin: kotaya uymak geçersiz yanıt şemasını doğru yapmaz. İstekler AI modellerine gidiyorsa dağılımı model kaydı ve maliyet kontrolleriyle tamamlayın. Hız, finansal harcama ve sonuç kalitesi bağlantılıdır, ama ayrı ölçüler ister.