n8n HTTP Request Node Kullanımı ve İpuçları

Otomasyon dünyasına biraz bulaşmış herkes bir noktada şunu fark eder: Zapier ya da Make.com gibi araçlar güzel, ama ya enterprise fiyatlandırma duvarına çarparsınız, ya da “bunu yapamam” mesajıyla karşılaşırsınız. n8n tam bu noktada devreye giriyor ve HTTP Request node’u bu aracın belki de en güçlü silahı.

Ben n8n’i production ortamına almadan önce yaklaşık iki ay sadece test ortamında çalıştırdım. Neden bu kadar uzun? Çünkü HTTP Request node’unun derinliğini kavramak zaman aldı. Basit görünüyor, bir URL giriyorsunuz, bir şeyler oluyor. Ama gerçekte bu node, REST API’lerle konuşmanın, webhook’ları tetiklemenin ve servisler arası veri köprüsü kurmanın kapısı.

HTTP Request Node Nedir ve Neden Bu Kadar Önemli?

n8n’deki built-in node’ların çoğu belirli bir servise odaklanır: Slack node’u Slack’e, PostgreSQL node’u PostgreSQL’e konuşur. Ama hayat bu kadar düzenli değil. Bazen iç sistemlerinizin API’si var, bazen küçük bir SaaS’ın n8n entegrasyonu yok, bazen kendinizin yazdığı bir microservice’e veri göndermeniz gerekiyor.

HTTP Request node bu durumların tamamını çözer. Herhangi bir HTTP endpoint’e GET, POST, PUT, PATCH, DELETE isteği atabilirsiniz. Authentication yönetimi yapabilirsiniz. Header, query parameter, body formatı belirleyebilirsiniz. Response’u parse edip sonraki node’lara aktarabilirsiniz.

Kısaca şunu söyleyeyim: Eğer bir servisin REST API’si varsa, HTTP Request node onu n8n’e bağlayabilir.

Temel Kullanım ve İlk İstek

Node’u canvas’a sürüklediğinizde sizi bir form karşılıyor. En kritik alanlar şunlar:

Method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
URL: İstek atılacak endpoint
Authentication: None, Basic Auth, Header Auth, OAuth2 vs.
Send Headers: Özel header eklemek için
Send Query Parameters: URL parametreleri
Send Body: POST/PUT isteklerinde veri göndermek için

Basit bir GET isteğiyle başlayalım. Diyelim ki bir iç API’nizden sunucu listesi çekmeniz gerekiyor:

# Test için curl karşılığı:
curl -X GET "https://api.sirketiniz.com/v1/servers" 
  -H "Authorization: Bearer TOKEN_BURAYA" 
  -H "Content-Type: application/json"

Bu isteği HTTP Request node’da karşılık şöyle kurarsınız:

Method: GET
URL: https://api.sirketiniz.com/v1/servers
Authentication: Header Auth
Header Name: Authorization
Header Value: Bearer TOKEN_BURAYA

Response otomatik olarak parse edilip sonraki node’a JSON olarak aktarılır.

Expression Kullanımı ile Dinamik URL’ler

Statik URL’ler işe yarıyor ama gerçek güç dinamik değerlerde saklı. n8n’in expression engine’ini HTTP Request node’da kullandığınızda işler ilginçleşiyor.

Örneğin bir önceki node’dan gelen server_id değerine göre dinamik endpoint çağırmak:

# Beklenen davranış:
# server_id = "srv-042" ise
# GET /v1/servers/srv-042/metrics çağrılmalı

URL alanına şunu yazarsınız:

https://api.sirketiniz.com/v1/servers/{{ $json.server_id }}/metrics

Süslü parantez sözdizimi n8n’in expression motoru. $json önceki node’un output’undaki JSON data’yı ifade eder. Bu sayede bir Trigger node’dan gelen her farklı sunucu ID’si için ayrı ayrı API çağrısı yapılır.

Birden fazla değeri kombine etmek de mümkün:

https://api.sirketiniz.com/v1/{{ $json.region }}/servers/{{ $json.server_id }}/{{ $json.metric_type }}

Bu esneklik özellikle Webhook trigger ile birleşince çok güçlü hale geliyor. Dışarıdan gelen request’teki parametrelere göre farklı API’lere yönlendirme yapabilirsiniz.

Authentication Tipleri ve Credential Yönetimi

Üretim ortamında neredeyse hiçbir API authentication olmadan çalışmaz. HTTP Request node birkaç farklı auth tipini destekliyor:

Basic Auth: Kullanıcı adı ve şifre. Eski sistemlerde sık görülür, özellikle internal araçlarda. Credential olarak kaydetmenizi öneririm, workflow’a gömmeyin.

Header Auth: Bearer token, API key gibi header tabanlı authentication. En yaygın kullanım:

# Postman eşdeğeri:
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
# veya
X-API-Key: abcd1234efgh5678

OAuth2: Özellikle Google, Microsoft gibi servislere bağlanırken. Token yenileme işlemini n8n otomatik hallediyor, bu büyük kolaylık.

Predefined Credential Type: Slack, GitHub gibi popüler servislerin credential tipleri built-in. Bunları seçince alanlar otomatik dolduruluyor.

Önemli bir pratik not: Credential’ları mutlaka n8n’in credential vault’unda saklayın. Workflow’un JSON export’unu aldığınızda credential değerleri maskeleniyor ama yine de iyi alışkanlık edinmek önemli.

POST İsteği ile Veri Gönderme

GET istekleri veri çekmek için güzel ama çoğu otomasyon senaryosu bir yerlere veri göndermek içeriyor. POST isteğinde Body konfigürasyonu kritik.

JSON Body: En yaygın format. Örnek senaryo: Monitoring sisteminden gelen alert’i Jira’ya ticket olarak açma.

# Curl karşılığı:
curl -X POST "https://jira.sirketiniz.com/rest/api/3/issue" 
  -H "Authorization: Basic BASE64_ENCODED_CREDS" 
  -H "Content-Type: application/json" 
  -d '{
    "fields": {
      "project": {"key": "OPS"},
      "summary": "Kritik alert: CPU kullanimi yüksek",
      "issuetype": {"name": "Bug"},
      "priority": {"name": "High"}
    }
  }'

n8n HTTP Request node’da Body Type olarak “JSON” seçip alanları doldurabilirsiniz. Ya da daha dinamik bir yaklaşım için “Specify Body” altında expression kullanabilirsiniz:

{
  "fields": {
    "project": {"key": "OPS"},
    "summary": "Kritik alert: {{ $json.alert_name }} - {{ $json.hostname }}",
    "issuetype": {"name": "Bug"},
    "priority": {"name": "{{ $json.severity === 'critical' ? 'High' : 'Medium' }}"}
  }
}

Form Data: Bazı eski API’ler JSON değil form data bekler. Body Type olarak “Form-Urlencoded” seçip key-value çiftleri girebilirsiniz.

Binary Data: Dosya upload senaryolarında kullanılır. n8n’deki bir önceki node’dan gelen binary veriyi multipart/form-data olarak gönderebilirsiniz.

Gerçek Dünya Senaryosu: Monitoring Alert’lerini Yönetmek

Şimdi daha somut bir örneğe geçelim. Prometheus/Alertmanager kurulumunuz var, alertlar n8n webhook’una geliyor ve siz bunları:

Slack’e bildiri olarak göndermek
Severity’ye göre Jira ticket açmak
Kendi iç CMDB API’nize log basmak

istiyorsunuz.

Bu workflow’da HTTP Request node üç farklı yerde kullanılır.

İlk kullanım: Slack notification. Slack webhook URL’inize POST atıyorsunuz:

curl -X POST "https://hooks.slack.com/services/T000/B000/XXXX" 
  -H "Content-Type: application/json" 
  -d '{
    "text": "🚨 Alert Aktif",
    "blocks": [
      {
        "type": "section",
        "text": {
          "type": "mrkdwn",
          "text": "*Alert:* CPU kullanimi %95 üzerinden*Sunucu:* prod-web-01n*Zaman:* 2024-01-15 14:32"
        }
      }
    ]
  }'

İkinci kullanım: IF node ile severity kontrolü yaptıktan sonra critical alert’ler için Jira API çağrısı. Yukarıdaki Jira örneği bu kısıma giriyor.

Üçüncü kullanım: CMDB’nize log basma. Bu tamamen şirket içi bir API ve herhangi bir ready-made integration yok. İşte HTTP Request node’un parlayan anı:

curl -X POST "https://cmdb.sirketiniz.com/api/v2/events" 
  -H "X-API-Key: internal-key-buraya" 
  -H "Content-Type: application/json" 
  -d '{
    "event_type": "alert_triggered",
    "source": "n8n_automation",
    "asset_id": "prod-web-01",
    "details": {
      "alert_name": "HighCPU",
      "value": 95.4,
      "threshold": 90
    },
    "timestamp": "2024-01-15T14:32:00Z"
  }'

Bu tüm senaryoyu n8n olmadan yazsaydınız, bir Python scripti, cron job, Slack SDK entegrasyonu, Jira client kütüphanesi ve CMDB için custom HTTP client yazmanız gerekirdi. n8n ile görsel olarak birbirine bağladınız, log görüntülüyorsunuz, hata durumunda retry var.

Pagination ile Büyük Veri Setleri

Bir API’den tüm kaydı çekmek istediğinizde genellikle pagination meselesiyle karşılaşırsınız. 1000 server’ınız var, API sayfa sayfa 100’er adet döndürüyor. HTTP Request node’un bu konuda native desteği var.

Pagination Type olarak şunları seçebilirsiniz:

Offset/Limit: ?page=1&limit=100 tarzı klasik pagination
Cursor-Based: Response’dan gelen cursor değeriyle sonraki sayfayı çekme
URL Based: Response içindeki “next” URL’ini takip etme

Cursor-based pagination örneği. GitHub Issues API’sini düşünelim:

# İlk istek:
GET https://api.github.com/repos/org/repo/issues?per_page=100

# Response header'ında gelir:
Link: <https://api.github.com/repos/org/repo/issues?per_page=100&page=2>; rel="next"

n8n bunu otomatik takip edebilir. Complete When alanına “All Pages” yazarsınız ve n8n “next” link’i kalmayıncaya kadar devam eder. Binlerce kayıt için çok pratik.

Offset-based için örnek konfigürasyon:

# Pagination expression:
# Offset: {{ $pageCount * 100 }}
# Limit: 100
# Continue While: {{ $response.body.data.length > 0 }}

Hata Yönetimi ve Retry Mekanizması

Production’da HTTP istekleri her zaman başarılı olmaz. Servis geçici olarak down olabilir, rate limit yiyebilirsiniz, timeout olabilir. HTTP Request node’un Options bölümünde bunlar için ayarlar var.

Retry on Fail: Kaç kez deneneceği ve denemeler arası bekleme süresi. Genellikle 3 retry, 5 saniye aralık iyi bir başlangıç noktası.

Timeout: Uzun süren API’ler için. Default 300 saniye ama bazı senaryolarda azaltmak gerekir.

Ignore SSL Errors: Internal sistemlerde self-signed sertifika kullanıyorsanız (kötü bir pratik ama gerçek hayat bu) bu seçenek var. Production’da kullanmayın.

Response kodlarına göre farklı davranış için IF node ile kombinasyon kurabilirsiniz:

# HTTP Response Code kontrolü:
# $response.statusCode >= 200 ve < 300 ise başarılı
# 429 ise rate limit, bekleme mantığı ekle
# 5xx ise servis hatası, alert gönder

n8n’in Error Trigger workflow’u ile birleşince çok güçlü bir hata yönetim sistemi kurabilirsiniz. HTTP Request başarısız olduğunda ayrı bir workflow tetiklenir, log tutulur, ilgili kişiye bildirim gider.

Query Parameter’larla Filtreleme

Birçok API filtreleme için query parameter kullanır. HTTP Request node’da bunları iki şekilde ekleyebilirsiniz: URL’e manuel yazabilir ya da “Add Query Parameter” alanını kullanabilirsiniz.

İkinci yöntem daha temiz ve expression kullanımına daha uygun:

# Zaman aralığına göre log çekme:
GET https://logs.sirketiniz.com/api/v1/entries
  ?from=2024-01-15T00:00:00Z
  &to=2024-01-15T23:59:59Z
  &level=ERROR
  &host=prod-web-01
  &limit=500

n8n’de bu parametreleri dynamic expression ile doldurursanız, örneğin tarih aralığını otomatik hesaplayabilirsiniz:

# "from" parametresi için expression:
{{ new Date(Date.now() - 24*60*60*1000).toISOString() }}

# "to" parametresi için:
{{ new Date().toISOString() }}

Bu sayede her gün çalışan bir schedule trigger’la dünkü log’ları çekip analiz ettirebilirsiniz.

Response’u İşleme ve Sonraki Node’a Aktarma

HTTP Request node’dan dönen veriyi anlamak ve bir sonraki adıma doğru şekilde geçirmek önemli.

Response tipik olarak şu şekilde gelir:

# Başarılı bir API response örneği:
{
  "status": "success",
  "data": {
    "servers": [
      {"id": "srv-001", "name": "prod-web-01", "status": "running"},
      {"id": "srv-002", "name": "prod-web-02", "status": "stopped"}
    ],
    "total": 2,
    "page": 1
  }
}

Bu response’dan sonraki node’da $json.data.servers ile server listesine erişirsiniz. Eğer array üzerinde işlem yapmak istiyorsanız, SplitInBatches ya da Item Lists node ile her server için ayrı ayrı işlem yapabilirsiniz.

Nested bir value’ya erişim:

# İlk server'ın adını almak için:
{{ $json.data.servers[0].name }}

# Tüm server ID'lerini almak için Function node'da:
return $json.data.servers.map(s => ({ id: s.id }));

Response Headers’a Erişim: Bazı durumlarda response header’ları da işe yarıyor. Örneğin rate limit bilgisi genellikle header’da gelir:

X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1705323600

Full Response seçeneğini aktifleştirirseniz, node output’u { headers: {}, body: {}, statusCode: 200 } şeklinde gelir ve header’lara $json.headers['x-ratelimit-remaining'] ile erişebilirsiniz.

Gerçek Dünya Senaryosu: GitLab Pipeline Durumunu İzleme

Ekibinizin GitLab pipeline’larını izlemek istediğinizi düşünelim. Her saat başı tüm aktif proje pipeline’larını kontrol edip, başarısız olanlar için ekibe Slack mesajı atmak istiyorsunuz.

# Adım 1: Tüm projeleri çek
GET https://gitlab.sirketiniz.com/api/v4/projects?membership=true&per_page=100
Authorization: Bearer GITLAB_TOKEN

# Adım 2: Her proje için son pipeline'ı çek
GET https://gitlab.sirketiniz.com/api/v4/projects/{project_id}/pipelines?per_page=1&status=failed
Authorization: Bearer GITLAB_TOKEN

# Adım 3: Başarısız pipeline varsa Slack'e bildir
POST https://hooks.slack.com/services/...

Bu workflow’u n8n’de kurarken:

Schedule Trigger: Her saat
HTTP Request (GitLab Projects): Tüm projeleri çeker, pagination ile
SplitInBatches: Her proje için ayrı işlem
HTTP Request (Pipeline Status): Her projenin son pipeline durumunu çeker
IF Node: $json[0].status === 'failed' kontrolü
HTTP Request (Slack): Başarısız pipeline’lar için bildirim

Toplam kurulum süresi: yaklaşık 45 dakika. Aynı şeyi Python ile yazsaydınız: GitLab kütüphanesi, Slack SDK, hata yönetimi, loglama, cron job, muhtemelen bir-iki gün.

Güvenlik ve Best Practice’ler

Üretim ortamında HTTP Request node kullanırken dikkat edilmesi gerekenler:

Credential yönetimi: API key’leri, token’ları asla workflow içine hard-code etmeyin. n8n’in credential sistemi şifreli saklıyor ve workflow export’larında maskeleniyor.

SSL doğrulama: Self-signed sertifika sorunlarını “Ignore SSL Errors” ile çözmek cazip ama güvensiz. Bunun yerine n8n’in çalıştığı sistemin CA store’una sertifikayı ekleyin:

# Ubuntu/Debian'da custom CA eklemek:
sudo cp sirketiniz-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# n8n environment variable ile custom CA:
NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.crt

Rate limiting: API’lerin rate limit’lerine saygı gösterin. SplitInBatches node’u ile birlikte Wait node kullanarak istekler arasına gecikme ekleyebilirsiniz.

Timeout değerleri: Uzun süren istekler için yüksek timeout koymak cazip ama bu workflow’un takılı kalmasına yol açar. Makul bir timeout + retry kombinasyonu daha iyi.

Sensitive data logging: n8n execution log’larında request ve response detayları görünür. Hassas veri içeren API’ler için “Don’t Save Execution Data” seçeneğini değerlendirin ya da ilgili alanları maskeleme mantığı ekleyin.

Sonuç

HTTP Request node, n8n’i gerçek anlamda evrensel bir otomasyon aracına dönüştüren şey. Hazır entegrasyonu olmayan her servise bu node ile ulaşabiliyorsunuz. Basit bir GET isteğinden OAuth2 korumalı, paginated, dinamik parametreli karmaşık API çağrılarına kadar her şey bu tek node üzerinden halledilebiliyor.

Ben şu an production’da 40’tan fazla aktif n8n workflow’u çalıştırıyorum ve bunların büyük çoğunluğunda HTTP Request node var. GitLab, Jira, Prometheus, kendi microservice’lerimiz, iş ortaklarının API’leri… Hepsine aynı node üzerinden konuşuyoruz.

Öğrenme eğrisi ilk bakışta dik görünse de, birkaç workflow yaptıktan sonra expression syntax’ına alışıyorsunuz ve işler akıyor. Tavsiyem şu: Önce curl ile test edin, ardından HTTP Request node’a taşıyın. İki dünyayı karşılaştırarak çalışmak en hızlı öğrenme yöntemi.

Son olarak şunu söyleyeyim: n8n’in self-hosted olması, tüm bu API entegrasyonlarını kendi altyapınızda tutmanızı sağlıyor. Hassas sistemlerinizin credential’larını üçüncü parti bir SaaS’a vermeden, kendi kontrolünüzde otomasyon kurabiliyorsunuz. Bu, kurumsal ortamlarda büyük bir avantaj.

n8n ile HTTP Request Node Kullanımı