n8n ve Zapier ne zaman yetmez? Özel otomasyona geçmeden önce on eşik ve hata testi

Önce dürüst cevap: iş süreçleri otomasyonu için çoğu zaman araç yeter

İş süreçleri otomasyonu için n8n ya da Zapier gibi bir araç çoğu zaman yeterlidir. Akış bozulduğunda maliyeti düşükse, birkaç adımdan oluşuyorsa, etkisi geri alınabiliyorsa ve birinin sorumluluğundaysa, özel yazılım yazmak gereksiz bir iş olur. Bu yazı araçları kötülemek için değil, tersini yapmak için var: araçta kalmanın doğru olduğu yerleri ayırmak ve ancak belirli bir eşik aşıldığında özel çözümü düşünmek. Eşikler genel bir uyarı değil, kendi akışınızda deneyip sonucunu göreceğiniz on hata testidir. Akışınızda bir yapay zeka adımı da varsa, yapay zeka entegrasyonu ve otomasyon sayfamız ve aşağıdaki hibrit yol bölümü ek sorular getirir.

Her testin dayanağı, aracın ya da ilgili servisin kendi belgesidir; belgeyi 2 Kasım 2026'da açıp okuduk ve yazının sonunda listeledik. Plan, sınır ve sürüm bilgisi zamanla değişir; bu yüzden hiçbir plan sınırını rakamla vermiyoruz, kendi planınızın güncel sayfasına bakmanızı söylüyoruz. Bir şeyi araç yapamıyor demiyoruz; yapıp yapmadığını sizin sınamanızı istiyoruz.

Üç soruyla ön eleme

Testlere başlamadan önce üç soru, çoğu akış için kararı verir.

1. Akış bozulursa ne kaybedersiniz? Bir bildirimin gecikmesiyle bir ödemenin iki kez alınması aynı ağırlıkta değildir. Maliyet düşükse araç yeter.
2. Akışın sahibi kim, o ayrılırsa ne olur? Akış tek bir kişinin hesabında, onun bildiği bir yapıda yaşıyorsa risk teknik değil, kurumsaldır.
3. Akış kendi planlama ufkunuzda ne kadar büyüyecek? Olay sayısı, adım sayısı ve akışa bağlı sistemler artıyorsa, bugünkü rahatlık yarın aynı kalmayabilir. Ufku ve ölçeği siz belirleyin; biz rakam vermeyiz.

Üçüne de "düşük" cevabını veriyorsanız araçta kalın ve aşağıdaki eşiklere yalnızca göz atın. Biri bile "yüksek" ise okumaya devam edin.

On eşik, on hata testi

Her eşik aynı dört satırdan oluşur: neden eşik, kendi akışınızda sınama, geçti ölçütü ve araçta çözüm yolu ya da özel yazılıma geçiş işareti. Sınamaları canlı veriyle değil, bir test ortamında ve uydurma veriyle yapın; her testi adım adım yürütün.

Eşik 1: Aynı olay iki kez gelirse

Neden eşik. Birçok servis aynı olayı birden fazla kez gönderebilir. Stripe'ın webhook belgesi aynı olayın birden fazla gelebileceğini söyler ve olay kimliklerini kaydetmenizi ister (Stripe). Zapier belgesine göre anlık tetikleyicilerde tekrarlı veriyi eleyen bir mekanizma yoktur ve eylem adımları hedef uygulamaya bağlı olarak kopya kayıt üretebilir (Zapier). n8n'in yeniden deneme belgesi, başarısız düğümün tüm öğeleri yeniden işlediğini ve daha önce gönderilmiş mesajların yeniden gönderileceğini yazar (n8n).

Kendi akışınızda sınama. Test akışına aynı olayı iki kez gönderin (aynı kimlikle). Hedefte kaç kayıt, kaç e-posta, kaç hareket oluştu?

Geçti ölçütü. İkinci olay hiçbir ek etki yaratmıyor.

Çözüm yolu ya da geçiş işareti. Araçta "güncelle ya da ekle" işlemleri ve olay kimliğiyle kontrol bir yol olabilir. Hedef sistem bunu desteklemiyorsa ve çift işlem para ya da müşteri iletişimi demekse, olay kimliğini saklayan küçük bir servis gerekir (hibrit bölüme bakın).

Eşik 2: İki olay aynı anda gelirse

Neden eşik. Stripe olayların sırayla gelmesinin sağlanmadığını yazar; olay kimliklerini izlemenizi ve eksik nesneyi API'den almanızı önerir (Stripe). n8n belgesine göre kendi sunucunuzda normal modda varsayılan bir üretim eşzamanlılık sınırı yoktur; Cloud'da sınırlar plana bağlıdır ve fazla çalıştırmalar sıraya girer (n8n; n8n Cloud).

Kendi akışınızda sınama. Aynı kayıt için (örneğin son stok birimi) aynı anda iki olay gönderin. Sonuç tutarlı mı, ikisi de başarılı mı oldu?

Geçti ölçütü. Tek kazanan var; ikinci olay kontrollü biçimde reddediliyor ya da sıraya giriyor.

Çözüm yolu ya da geçiş işareti. Aracın belgesinde sıra ya da kilit davranışı arayın; varsaymayın. Böyle bir davranış yoksa ve kayıt tutarlılığı iş için kritikse, kilidi veri katmanında tutan bir servis düşünün.

Eşik 3: Akış yarıda kalırsa

Neden eşik. Akışın üç adımı olduğunu varsayın: kayıt oluştur, ödeme al, e-posta gönder. İkinci adımdan sonra çökerse yeniden denemenin ne yapacağı belirleyicidir. n8n'de yeniden deneme kayıtlı durumdan devam eder ama başarısız düğüm tüm öğeleri yeniden işler. Zapier'de tüm Zap çalışmasını yeniden oynatmak tetikleyici dahil her adımı yeniden çalıştırır ve yeni bir çalışma sayılır; hatalı adımın yeniden oynatılması ayrıdır (Zapier). Zapier belgesi ayrıca, zaman aşımından sonra eylemin yeniden oynatılmasının kopya veri üretebileceğini söyler (Zapier).

Kendi akışınızda sınama. Orta adımı bilerek hata verecek şekilde ayarlayın (n8n'de Stop And Error düğümü bunun için var), sonra yeniden deneyin. Hangi adımlar iki kez çalıştı?

Geçti ölçütü. Yeniden deneme, daha önce tamamlanmış adımların etkisini tekrarlamıyor ya da akış yarım kalan durumu görünür kılıp insana bırakıyor.

Çözüm yolu ya da geçiş işareti. Her adımı yeniden çalıştırılabilir (idempotent) tasarlamak mümkünse araçta kalınır. Adımlar arasında geri alma ya da telafi gerekiyorsa özel yazılım işaretidir.

Eşik 4: Hatayı kim, ne zaman öğrenir

Neden eşik. Gürültülü bir hata değil, sessiz bir durma en pahalı olanıdır. n8n'de hata iş akışı, çalışma başarısız olduğunda devreye girer ve Error Trigger ile başlamalıdır; belge, hata iş akışının elle çalıştırmayla test edilemediğini, yalnızca otomatik bir çalışma hata verdiğinde tetiklendiğini belirtir (n8n). Zapier'de çalışmalar hatalı, güvenle durdurulmuş, beklemede ya da hata yönetilmiş gibi farklı durumlarla görünür; bir Zap tekrar tekrar hata verirse otomatik olarak kapanır (Zapier). Yani akışın durduğunu fark etmek, birinin panele bakmasına ya da bir bildirime bağlıdır.

Kendi akışınızda sınama. Bir hatayı zorlayın ve zamanı yazın. Kim, hangi kanaldan, ne kadar sonra haberdar oldu? Sonra bir de hiç çalışmayan bir akış düşünün: "hiçbir şey olmadı" nasıl fark edilir?

Geçti ölçütü. Hata bir insana ulaşıyor, mesajda ne olduğu ve hangi çalışma olduğu var; hiç çalışmama da bir sinyal üretiyor.

Çözüm yolu ya da geçiş işareti. Araçta hata akışı ve düzenli bir "çalıştı mı" kontrolü kurulabilir. Ölçülen hizmet düzeyi ya da aylar sonra bile aranacak bir iz gerekiyorsa özel izleme düşünün.

Eşik 5: Test, sürüm, geri alma

Neden eşik. Canlı bir akışı düzenlemek, bozulursa geri dönebilmeyi gerektirir. n8n'de kaynak denetimi ve ortamlar Business ve Enterprise planlarında sunuluyor (n8n); değişiklik geçmişinin derinliği plana bağlıdır. Zapier'de taslaklar tüm planlarda vardır ve Zap çalışırken düzenlenebilir, sürüm geçmişinin uzunluğu plana bağlıdır ve Free planda yoktur; belge ayrıca, kapsamlı değiştirilmiş bir Zap'in eski adımlarının yeniden oynatılamayacağını söyler (Zapier).

Kendi akışınızda sınama. Test akışında bir değişiklik yapın, bozun, önceki sürüme dönmeyi deneyin. Ne kadarı geri geldi, ne kadar sürdü? Değişikliği canlıya almadan önce birinin gözden geçirmesi mümkün mü?

Geçti ölçütü. Önceki çalışan sürüme dönüş yazılı ve denenmiş; değişikliği kimin yaptığı ve ne zaman yaptığı görülüyor.

Çözüm yolu ya da geçiş işareti. Planınızın sunduğu sürüm ve ortam özelliği yeterliyse araçta kalın. Kod incelemesi, ayrı test ortamı ve otomatik testler gerekiyorsa özel yazılım bunların doğal yeridir.

Eşik 6: Kimlik bilgisi kimin hesabında

Neden eşik. Akış, bir kişinin hesabıyla kurulmuş bağlantılara dayanır. Zapier'de bağlantılar varsayılan olarak özeldir; paylaşıldığında alıcılar kimlik bilgisini görmeden kullanabilir ve adımları düzenleyebilir, bağlantının sahibi erişimi yitirirse Zap duraklar (Zapier). n8n'de bir iş akışının oluşturanı, kullanıcı silinmedikçe değiştirilemez; düzenleyiciler akışta kullanılan tüm kimlik bilgilerini, açıkça paylaşılmamış olanlar dahil kullanabilir (n8n).

Kendi akışınızda sınama. Akıştaki her bağlantının kimin hesabında olduğunu listeleyin. O kişinin erişimi kapansa ne olurdu? Bunu test hesabıyla deneyin.

Geçti ölçütü. Her bağlantı ortak bir kurum hesabında ya da adlandırılmış bir sahipte; sahip değişirse akış çalışmaya devam ediyor.

Çözüm yolu ya da geçiş işareti. Kimlik bilgisi sahipliği araçta ortak hesapla çözülür. Kimin neye eriştiğini ayrıntılı ve denetlenebilir biçimde sınırlamak gerekiyorsa özel çözüm.

Eşik 7: Hacim ve hız sınırları

Neden eşik. Zapier'in webhook belgesi, sınırın aşılmasında 429 durum kodu döndüğünü, 200 kodunun işlemenin birkaç dakika gecikmesiyle gelebileceğini ve üstel geri çekilmeyle yeniden denemeyi önerir (Zapier). Stripe da olayların sıraya alınarak asenkron işlenmesini ve ani artışların sunucuyu aşırı yükleyebileceğini söyler (Stripe). n8n'de sıraya giren çalışmalar yeniden denenemez; yani yük altında sıradaki bir olayın akıbetini ayrıca izlemeniz gerekir. Sınırlar plana göre değişir; kendi planınızın sayfasına bakın.

Kendi akışınızda sınama. Test ortamında kısa sürede çok sayıda olay gönderin, yoğun saatinizi taklit edin. Hangileri gecikti, hangileri kayboldu, gönderen taraf ne gördü?

Geçti ölçütü. Yoğun saatte hiçbir olay kaybolmuyor; gecikme iş için kabul edilebilir.

Çözüm yolu ya da geçiş işareti. Daha yüksek bir plan ya da sıraya alma çözebilir. Beklenen yük, plan sınırlarının tek tek hesaplanamayacağı kadar düzensizse özel bir kuyruk gerekir.

Eşik 8: İzlenebilirlik ve kayıt süresi

Neden eşik. "Bu müşteriye o e-posta neden gitti?" sorusuna bir ay sonra cevap verebilmeli. Zapier'in Zap geçmişi belgesi, Zapier'in en fazla 60 günlük çalışma verisini taahhüt edebildiğini ve en fazla 10.000 çalışma gösterdiğini yazar; daha uzun süreli kayıt için geçmişin düzenli olarak dışa aktarılmasını önerir (Zapier; 2 Kasım 2026 itibarıyla). n8n'de çalışma verisi budama varsayılan olarak açıktır; yaş ve sayı sınırı ayarlanabilir, çalışmaların kaydedilmemesi de seçilebilir (n8n). Kayıtlarda kişisel veri varsa 6698 sayılı Kanun'un 12. maddesindeki veri güvenliği yükümlülüğü gündeme gelir; bu bir hukuki danışmanlık değil, yalnızca maddeye işarettir.

Kendi akışınızda sınama. Bir test çalışması üretin ve belirli bir kaydın akıştan geçtiğini, hangi adımda ne verdiğini gösterin. Kayıtlar ne kadar süre duruyor, kim okuyabiliyor?

Geçti ölçütü. Bir kaydın akıştan geçişi, ihtiyaç duyduğunuz süre boyunca bulunabiliyor; kayıtta neyin tutulduğu yazılı.

Çözüm yolu ya da geçiş işareti. Çalışma verisini araç dışına aktarmak bazen yeterlidir. Tutulması gereken süre aracın saklama süresini aşıyorsa ya da düzenleyici bir kayıt gerekiyorsa, kaydı sizin veri katmanınızda tutun.

Eşik 9: Okunabilirlik (mühendislik yargısı)

Neden eşik. Bu eşik için bir belge dayanağı yok, mühendislik yargımızdır. Büyüyen bir görsel akışı kimse tam olarak okuyamaz hale gelir. n8n belgesi, büyük iş akışlarını alt iş akışlarına bölmeyi modülerlik için önerir (n8n).

Kendi akışınızda sınama. Akışı hiç görmemiş birinden onu yüksek sesle anlatmasını isteyin; ne yaptığını, nerede hata olabileceğini ve neyi değiştirmemesi gerektiğini sorun.

Geçti ölçütü. O kişi akışı bir sayfalık açıklamayla anlayabiliyor, özel durumları buluyor.

Çözüm yolu ya da geçiş işareti. Alt akışlara bölmek ve açıklama notları eklemek yardımcı olur. Açıklama bir sayfaya sığmıyorsa ve akışta iş kuralları birikmişse, bunları kodda ve testlerle tutmak daha sürdürülebilirdir.

Eşik 10: Veri, lisans, çıkış

Neden eşik. Aracı bırakmak istediğinizde elinizde ne kalır? n8n'in Sustainable Use License (Sürdürülebilir Kullanım Lisansı) koşulları, kendi iç iş kullanımına ve ticari olmayan ya da kişisel kullanıma izin verir; ürünü müşterilere sunmak gibi diğer kullanımlar ayrı bir anlaşma gerektirir (n8n). n8n iş akışları JSON olarak dışa aktarılır; dışa aktarma kimlik bilgilerinin adlarını ve kimliklerini içerir, paylaşmadan önce temizlenmelidir (n8n). Zapier'de dışa aktarma ve çoğaltma sürümleri içermez.

Kendi akışınızda sınama. Akışı dışa aktarın. Başka bir ortamda, o araç olmadan neyin yeniden kurulabileceğini yazın.

Geçti ölçütü. Çıkış yolu yazılı: ne dışa aktarılıyor, ne kayboluyor, lisans kullanımınıza izin veriyor.

Çözüm yolu ya da geçiş işareti. Lisansın izin verdiği kullanım alanını kendi durumunuzla karşılaştırın; araç ürünün bir parçası olacaksa lisans metnini mutlaka doğrulayın (bu bir hukuki yorum değildir). Akışın tek kopyası aracın içindeyse ve onu aracın dışında anlatamıyorsanız, bu bir özel yazılım işaretidir.

Sonucu okumak: kırmızı, sarı, yeşil ve karar

Sonuçları aşağıdaki tabloya yazın. Eşikler bizim mühendislik yargımızdır, standart değildir. 1, 2, 3, 4 ya da 6. eşiklerden biri kırmızıysa, bir işletim önlemi eklemeden kritik akışı araçta bırakmayın.

Renkleri şöyle okuyun: kırmızı testin geçmediği ve sonucun iş için kabul edilemez olduğu durumdur; sarı geçmeyen ama etkisi sınırlı ve bir önlemle yönetilebilen durumdur; yeşil testin geçtiği durumdur. "Bilinmiyor" sonucu yeşil sayılmaz: bir sınama işi olarak yazın, sahibini ve tarihini belirleyin. Aynı sonuç bir akışta sarı, bir başkasında kırmızı olabilir, çünkü ön eleme sorusundaki bozulma maliyeti her akışta farklıdır. Dört karar mümkün: araçta kal (kırmızı yok, sarılar yönetilebilir); araca işletim önlemi ekle (kırmızı ya da sarı var ve çözüm araç içinde: hata bildirimi, olay kimliği kontrolü, ortak hesap); hibrit (1, 2, 3, 4 ya da 6'dan biri kırmızı, araçta çözüm yok ve sorun tek bir kritik adımda toplanıyor: o adım küçük bir servise taşınır); özel yazılım (aynı kırmızı, ama sorun tek bir adımla sınırlı değil, akışın bütününe yayılıyor). Birden çok akışınız varsa şu çalışma sayfasını kullanın: her akış bir satır; sütunlar on testin sonucu (geçti, kaldı ya da bilinmiyor), sahibi, iş etkisi ve karar.

Hibrit yol: araç yönetir, küçük bir servis kritik adımı yapar

Çoğu zaman en iyi karar ikisinin arasındadır. Akış araçta kalır; yalnızca eşik 1, 2 ve 3'ü zorlayan adım küçük bir servise gider. Servis, Stripe'ın idempotent istekler belgesinde anlatılan mantığı kullanır: bir idempotency anahtarı aynı işlemin iki kez yapılmadan güvenle yeniden denenmesini sağlar (Stripe); kilit de servisin içinde tutulur. Bedeli açık: artık işletilecek iki şey var, araç ve servis. Akışta bir yapay zeka adımı varsa yapay zeka entegrasyonu üretime çıkış kontrol listesi ek maddeleri verir. Servisi yapay zeka araçlarıyla yazdırdıysanız aynı ilke vibe coding uygulaması üretime hazır mı denetiminde de geçerlidir. Kararı toplam maliyet açısından tartmak için hazır yazılım mı özel yazılım mı çalışma sayfasına bakabilirsiniz.

Özel yazılıma geçerken ne taşınır?

Mevcut akış, yeni sistemin gereksinim belgesidir. Dışa aktarılmış akış, "bu akış ne yapar" belgesi ve yukarıdaki hata testleri, kabul ölçütlerine dönüşür: yeni sistem, eski akışın geçemediği testlerden geçmeli, geçtiği testlerde de aynı sonucu vermeli. "Bilinmiyor" kalan testler de kapsama girer: yeni sistemin neyi kanıtlaması gerektiği, eski akışın neyi bilmediğinizle birlikte yazılmalıdır. Bunu yazılı bir kapsamda nasıl ifade edeceğiniz için Kapsam belgesi (SOW) şablonunun "Teslimatlar ve kabul ölçütleri" maddesine bakın.

İki gerçek desen

Aşağıdaki iki örnek, eşiklerin gerçek bir sistemde neye benzediğini gösterir; araç karşılaştırması değildir ve bir aracın bunu yapıp yapamayacağı hakkında hüküm içermez.

• Kuyruğa alma deseni (eşik 7'ye yakın). Portfolyomuzdaki ön muhasebe ve faturalama platformunda durum güncellemeleri Stripe'ın webhook'larından, Redis üzerinden kuyruğa alınarak geliyor; yani durum, birinin hatırlayıp güncellemesine değil, gerçekten ödenene bağlı.
• Eşik 2'ye benzeyen desen. Rezervasyon platformunda iki kişi aynı saate ulaşabiliyor; bu yüzden müsaitlik yazmaları bir Postgres işlem kilidinden geçiyor: ilk istek kazanıyor, ikincisi dürüst bir "zaten alındı" cevabı alıyor.

Biz bunu nasıl yapıyoruz

Her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır. Kapsam, takvim ve maliyet, herhangi bir ücretlendirme başlamadan önce yazılı olarak elinizde olur; onayınızdan önce tahsilat yoktur. Hazır çözüm işinizi görüyorsa bunu söyleriz. Sonra ne yapılacağını, hangi sırayla ve ne kadara olacağını yazıya döküyoruz; siz onaylamadan iş başlamaz. Yapay zeka ve otomasyonu aynı sayfada ele alırız; her otomasyon yapay zeka gerektirmez ve yapay zekanın doğru çözüm olmadığı bir durumla karşılaşırsak bunu da söyleriz. Her teknik kararın nedenini yazılı hale getiririz. API anahtarları ve üçüncü taraf hesaplar şifrelenerek saklanır, yalnızca sizin projenizde kullanılır ve iş bittiğinde bunları değiştirmekte ya da iptal etmekte özgürsünüz. Adımları Süreç sayfasında, yazılım tarafını özel yazılım geliştirme sayfamızda anlatıyoruz. Projenizi anlatın.

Sık sorulan sorular

n8n ve Zapier ne zaman yetmez?

İş süreçleri otomasyonunda akışın bozulmasının maliyeti yüksekse, 1, 2, 3, 4 ya da 6. testte kırmızı alıyorsanız ve aracın işletim önlemleri de sorunu çözmüyorsa araç yetmez. Eşiklerin dayanağı aracın kendi belgesidir; kendi akışınızda sınamadan karar vermeyin.

n8n mi Zapier mi?

Bir öneri yapmıyoruz; yeterlilik akışınızın testlerine ve planınıza bağlı. Belgelerde karşılaştıracağınız ölçütler şunlar: sürüm ve ortam özellikleri, hata iş akışları, çalışma geçmişi süresi, lisans ve barındırma biçimi (kendi sunucunuzda mı, bulutta mı).

Kodsuz otomasyon güvenli mi?

Güvenlik aracın değil, kurulumun sonucudur. Kimlik bilgilerinin kimin hesabında olduğuna (eşik 6) ve kayıtlarda neyin, ne kadar süre tutulduğuna (eşik 8) bakın. Bu genel bilgidir, hukuki danışmanlık değildir.

WhatsApp ile otomasyon ya da chatbot kurabilir miyim?

WhatsApp'ın iş mesajlaşma politikası (23 Eylül 2026'da güncellenmiş) 24 saatlik müşteri hizmetleri penceresi içinde otomasyona izin verir, ama hızlı, açık ve doğrudan bir yükseltme (escalation) yolunu şart koşar (WhatsApp). Kanal sorusunun ayrıntısı için yapay zeka entegrasyonu sayfamıza bakın.

Özel otomasyona geçmek ne zaman mantıklı?

Şu dört işaretten biri kırmızıysa ve araçta çözümü yoksa: çift ya da eşzamanlı olayın işi bozması (eşik 1, 2), yarım kalan akışı geri alamamak (eşik 3), hatayı zamanında öğrenememek (eşik 4) ya da kimin neye eriştiğini denetlenebilir biçimde sınırlayamamak (eşik 6). Bu durumlarda önce hibrit yolu, sonra özel yazılımı değerlendirin.

Kaynaklar

Aşağıdaki sayfalar 2 Kasım 2026'da açılıp okundu. Plan, sınır ve sürüm bilgisi taşıyan sayfalar zamanla değişebilir.

• n8n belgeleri: hatalarla başa çıkma · Error Trigger · çalışmalar ve yeniden deneme · kaynak denetimi ve ortamlar · değişiklik geçmişi · çalışma verisi yönetimi · eşzamanlılık · Cloud eşzamanlılığı · paylaşım · dışa aktarma · alt akışlar · topluluk lisansı
• Zapier Yardım Merkezi: Zap geçmişi · yeniden oynatma · taslaklar ve sürümler · hata durumları · tekrarlı veri · kopya veri · webhook sınırları · bağlantı paylaşımı
• Stripe: webhook'lar · idempotent istekler
• WhatsApp Business Messaging Policy
• 6698 sayılı Kanun, mevzuat.gov.tr (m. 12)

Bu yazı genel bilgi içindir; hukuki danışmanlık değildir. 8. eşikteki mevzuat atfı yalnızca ilgili maddeye işaret eder, yorum içermez.