No-code ortamda API entegrasyonu kurma rehberi

Kod yazmadan API bağlantısı mümkün mü ve nerede sınırı var?

Evet. Otomasyon araçlarının çoğunda hazır uygulama bağlayıcıları vardır: bir hesabı tanıtırsınız, araç gerisini yapar. Ama her hizmetin hazır bağlayıcısı olmaz ya da bağlayıcı ihtiyacınız olan işlemi kapsamaz. Bu durumda genel bir HTTP istek düğümü kullanılır. Bu düğümle herhangi bir hizmetin API'sine istek göndermek mümkündür; kod yazmazsınız, ama isteğin nasıl kurulduğunu anlamanız gerekir.

Sınır burada başlar. No-code, kod yazma yükünü kaldırır, fakat API mantığını anlama gerekliliğini kaldırmaz. Adres, yöntem, kimlik doğrulama, istek gövdesi ve yanıt yapısı bilinmeden bağlantı kurulamaz. Bu beceri, bu kavramları teknik olmayan bir kullanıcının kavrayabileceği biçimde öğrenmekle ilgilidir.

API dokümantasyonu nasıl okunur?

Her bağlantı, hizmetin API dokümantasyonuyla başlar. Dokümantasyonda aranacaklar şunlardır:

• Temel adres: isteklerin gönderileceği ana URL
• Uç noktalar: her işlem için ayrı yol (örneğin müşteri listesi, sipariş oluşturma)
• HTTP yöntemi: veri almak için genellikle GET, oluşturmak için POST, güncellemek için PUT ya da PATCH, silmek için DELETE
• Kimlik doğrulama: API anahtarı, taşıyıcı jeton ya da kullanıcı adı ve parola
• İstek parametreleri: zorunlu ve isteğe bağlı alanlar
• Yanıt örneği: dönen verinin yapısı
• Hız sınırları ve hata kodları

Dokümantasyonda çoğunlukla curl komutu örnekleri bulunur. Otomasyon araçlarının bir kısmı bu komutu doğrudan içe aktarıp alanları kendiliğinden doldurur; n8n'in HTTP Request düğümünde bunun için Import cURL seçeneği vardır.

HTTP istek düğümü nasıl yapılandırılır?

n8n belgelerine göre HTTP Request düğümünün ana ayarları şunlardır: Method (DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT), URL, Authentication, Send Query Parameters, Send Headers ve Send Body. Kimlik doğrulamada n8n'in desteklediği hizmetler için Predefined Credential Type seçilebilir; desteklenmeyenlerde Basic auth, Header auth, OAuth2 API ya da Query auth gibi genel seçenekler kullanılır. Gövde türleri arasında Form URLencoded, Form-Data, JSON, n8n Binary File ve Raw bulunur.

Çalışan bir kurulum örneği: bir hizmetin müşteri listesini çekmek için yöntem GET seçilir, uç nokta adresi yazılır, kimlik doğrulama bilgisi başlık olarak eklenir, filtre için sorgu parametreleri girilir. Düğüm çalıştırıldığında yanıt önizlemede görünür. Önce küçük bir deneme isteğiyle yapı doğrulanır, sonra gerçek verilerle genişletilir.

Kimlik doğrulama yöntemleri ve gizli bilgilerin saklanması

API'ler genellikle kimlik doğrulama ister. En yaygın yöntemler API anahtarı, taşıyıcı jeton (Bearer) ve kullanıcı adı-parola ikilisidir. Daha gelişmiş hizmetler yetkilendirme akışı kullanır; bu durumda kullanıcı hizmete giriş yapıp izin verir ve araç jetonu otomatik yeniler. Otomasyon aracının hazır bağlayıcısı varsa bu akışı çoğu zaman tek tıkla kurar.

Gizli bilgiler akışın içine metin olarak yazılmaz. Araçların kimlik bilgisi yönetimi bölümünde saklanır, akışlarda yalnızca ada başvurulur. Böylece akış paylaşıldığında ya da kopyalandığında anahtar sızmaz. Anahtarların yalnızca gereken yetkiyle oluşturulması da önemlidir; okuma yapacak akışa silme yetkisi verilmez.

JSON verisini okumak ve akışta kullanmak

API'lerin büyük bölümü yanıtı JSON biçiminde döndürür. JSON, anahtar-değer çiftlerinden oluşur; iç içe nesneler ve listeler içerebilir. No-code araçta yanıt, düğüm çıktısında ağaç görünümüyle okunur ve sonraki düğümlerde alan adı seçilerek kullanılır. Örneğin müşteri adı ve e-posta alanları ayrı ayrı sonraki adıma aktarılabilir.

Gönderirken de JSON kurulur. Bir kayıt oluşturmak için gövdeye alan adlarını ve değerlerini tanımlarsınız; değerler önceki adımlardan değişken olarak alınır. Alan adı hatası, tür uyumsuzluğu (metin yerine sayı beklenmesi) ve zorunlu alanın eksikliği en yaygın hata nedenleridir. Hata mesajı çoğu zaman hangi alanın sorunlu olduğunu söyler.

Sayfalama, hız sınırı ve hata yönetimi

Bir liste büyükse API tüm kayıtları tek yanıtta vermez; parçalar halinde döndürür. Buna sayfalama denir. n8n'in HTTP Request düğümünde Pagination seçeneği vardır; belgelere göre kip olarak Off, Update a Parameter in Each Request ve Response Contains Next URL seçilebilir. Hangisinin kullanılacağı API'nin sayfalama biçimine bağlıdır, bu da dokümantasyondan öğrenilir.

Hizmetler kısa sürede çok istek gelirse hız sınırı uygular. Yoğun akışlarda bekleme düğümü eklemek ve toplu işlemleri parçalamak bu sınırlara takılmayı önler. Hata durumunda akışın nasıl davranacağı da planlanır: yeniden deneme, alternatif kola yönlendirme ya da bildirim gönderme. Sessizce başarısız olan bir bağlantı, veri kaybına yol açar.

Örnek senaryo ve sık yapılan hatalar

Örneğin yeni bir sipariş geldiğinde bir kargo hizmetinin API'sine gönderi oluşturma isteği atılsın. Akış, siparişten adres ve ürün bilgisini alır, JSON gövdesini kurar, isteği POST ile gönderir, yanıttaki takip numarasını siparişe yazar. Başarısız olursa ekibe bildirim gider.

Sık hatalar:

• Dokümantasyonu okumadan deneme yanılmaya girişmek
• Anahtarı akışa düz metin olarak yazmak
• Yöntem veya içerik türü başlığını yanlış seçmek
• Sayfalamayı atlayıp yalnızca başlangıç sayfasındaki veriyi almak
• Hız sınırını hesaba katmamak
• Üretim verisi üzerinde silme veya güncelleme isteğini denemeden çalıştırmak

Güvenli yol, önce test ortamı ya da tek kayıtla denemek, sonra toplu işleme geçmektir.

Bu beceri Mindset programlarında nerede çalışılır?

n8n ile Kod Yazmadan AI Asistanı Tasarımı Eğitimi'nin Veri Kaynakları ve API Bağlantıları ile Gelişmiş Özellikler ve Otomasyon Senaryoları başlıkları bu konuya yakındır. Operasyon, pazarlama ve BT ekiplerinden iş akışı kuranlar için uygun bir yapıdır.

İş Süreçlerinde AI Otomasyonu programı ise Make ile AI Otomasyonu ile Zapier ve Power Automate ile Kurumsal Entegrasyon başlıklarını içerir; böylece farklı araçlarda aynı API bağlantısı mantığı karşılaştırılabilir.