1. Webhook Nedir?
Webhook, bir sistemde bir olay gerçekleştiğinde (ör. “publish”) başka bir sisteme HTTP üzerinden “haber vermek”tir. Klasik entegrasyonlar “polling” yapar: site gidip CMS’i sürekli sorar. Webhook ise tersine çalışır: CMS olayı olduğunda sizi çağırır. Sonuç; daha düşük gecikme, daha az manuel iş ve daha net operasyon.
CMS webhook nedir, ne işe yarar?
Kısa cevap: CMS’te publish/update/delete gibi olaylar olduğunda, belirlediğiniz endpoint’e otomatik istek atarak revalidation, bildirim veya entegrasyon tetikleyen mekanizmadır.
Webhook’ların en doğru kullanımı, “tek bir devasa akış” değil; küçük ve güvenli tetiklerdir:
- •Yayınlandı → revalidate + Slack mesajı
- •Silindi → ilgili sayfayı kaldır + indeks güncelle
- •Kritik içerik güncellendi → partner sisteme uyarı
Ne yapmalıyım?
- • Olayları listele: publish/update/delete (draft dahil mi?)
- • Her olay için hedef aksiyon tanımla (revalidate/bildirim/CRM).
- • Endpoint güvenliğini baştan planla (secret + rate limit).
- • Log/izleme ekle (başarılı/başarısız).
- • Önce küçük bir akışla başla (publish→revalidate).
2. CMS’te Publish/Update/Delete Olaylarını Dinlemek
En büyük hata, “update” ile “publish”i karıştırmaktır. Birçok CMS’te draft kaydı da update sayılır; o yüzden “update” event’ini doğrudan prod tetiklemek risklidir. Bu bölümde hangi olayın ne anlama geldiğini netleştiriyoruz.
Event seçiminde 3 kritik kural
- Publish: Prod’a yansıyacak aksiyonlar (revalidation, Slack)
- Update: Sadece “published entry updated” filtreli kullan (Varsayım: CMS destekliyorsa)
- Delete/Unpublish: 404/redirect, indeks güncelleme ve cache purge
Payload standardı (minimum)
Webhook payload’ında şu bilgiler yoksa sonradan acı çekersiniz:
- •event_type (publish/update/delete)
- •content_type (blog, room, campaign, document)
- •entity_id
- •slug/path
- •locale (çok dilli ise)
- •timestamp
- •signature/secret doğrulama bilgisi
Ne yapmalıyım?
- • Draft olaylarını prod tetiklerinden ayır (preview/staging’e yönlendir).
- • “Published update” filtreleri ile risk azalt.
- • Delete/unpublish için redirect/404 planı yaz.
- • Payload standardını dokümante et.
- • Hatalı payload’ı “reject” eden validasyon ekle.
3. Static Rebuild/ISR Revalidation Tetiklemek
Next.js tarafında en sık hedef: içerik yayınlanınca sayfanın hızlı güncellenmesi. ISR revalidation; “tüm siteyi build et” yerine ilgili sayfaları yenilemeyi sağlar. Bu da hem hız hem maliyet avantajı demektir.
Yeni içerik yayınlandığında Next.js’i nasıl tetiklerim?
Kısa cevap: CMS’ten webhook ile güvenli bir endpoint’e istek gönderin; endpoint doğrulama sonrası ilgili path’ler için revalidate çağrısı yapar.
SSG vs ISR vs full rebuild (kısa karar çerçevesi)
- •Full rebuild: büyük değişiklikler veya geniş etki (nadir)
- •ISR revalidation: içerik sayfası güncellemeleri (çoğu senaryo)
- •Parçalı güncelleme: fiyat/widget gibi dinamik bileşenler (ayrı katman)
Ne yapmalıyım?
- • Revalidate endpoint tasarla (tek iş: doğrula + revalidate).
- • Path üretimini payload’dan yap (blog slug / oda slug / kampanya).
- • Full rebuild’i sadece istisnaya bırak.
- • Publish→live SLA belirle ve ölç.
- • Hata tekrarında retry/backoff kuralı koy.
4. Dış Sistemlere Bildirim (CRM, Slack, Search Index vb.)
Webhook’ların gücü, yalnız revalidation değil; ekip ve sistem senkronudur. Yayınlanan içeriğin CRM kampanyasına bağlanması, Slack’te ekip bilgilendirmesi, indeksin güncellenmesi gibi adımlar; “yayın sonrası unutulan işleri” otomatikleştirir.
Slack/Teams bildirimleri (örnek)
- •Blog yayınlandı → #content kanalına link + etiket + owner
- •Kritik sayfa güncellendi (oda/kampanya) → #ops kanalına uyarı
- •Delete/unpublish → #seo kanalına 404/redirect hatırlatması
CRM tetikleri (B2B whitepaper örneği)
- •Whitepaper yayınlandı → CRM’de kampanya aktif et, nurture başlat
- •Form sayfası güncellendi → dönüşüm takibi notu / Tag Manager kontrol checklist’i (Internal Link Targets ile uyum)
Arama indeksi / site haritası güncellemesi
- •Yeni içerik yayınlandı → sitemap ping / index update tetiklenir (Varsayım: kullandığınız altyapıya göre)
| Olay | Tetiklenen aksiyon | Hedef sistem | Operasyon notu |
|---|---|---|---|
| publish | İlgili path için ISR revalidation | Next.js | Payload içindeki slug/path ve locale ile hedefli çalışır |
| publish | İçerik yayına alındı bildirimi | Slack/Teams | #content kanalına link + owner + içerik tipi gönderilir |
| update | Kritik sayfa güncellendi uyarısı | Slack/Teams | Sadece published update filtreli kullanılmalıdır |
| delete/unpublish | 404/redirect kontrol hatırlatması | SEO/ops kanalı | İndeks ve yönlendirme aksiyonu unutulmaz |
| publish | Kampanya veya nurturing tetik sinyali | CRM | Whitepaper/demo gibi yüksek niyet içeriklerde kullanılır |
Ne yapmalıyım?
- • Bildirimleri kanala göre segmentle (content/ops/seo).
- • CRM tetiklerini “yüksek niyet” içeriklere bağla (whitepaper/demo).
- • Search index/sitemap güncellemelerini otomatikleştir.
- • Bildirim payload’ını standartlaştır (title, url, type, owner).
- • Gürültüyü azalt: sadece publish ve kritik update’ler.
5. Otel ve B2B İçin Otomasyon Örnekleri
Bu bölüm, “neden yapalım?” sorusunu sahaya indirir: otelde hız ve tutarlılık; B2B’de pipeline ve içerik lansmanı.
Otel senaryosu 1 — kampanya yayını
- •CMS kampanya publish → Next.js revalidate (landing)
- •Ops Slack → “kampanya canlı” bildirimi
- •(Varsayım) fiyat bileşeninde cache purge/revalidate → eski fiyat riski azalır
Otel senaryosu 2 — oda içeriği güncellemesi
- •Oda açıklaması/görsel update → oda sayfası revalidate
- •SEO ekibine bildirim → snippet/metadata kontrol
- •(Partner) PMS/Channel Manager’a içerik değil, sadece uyarı/etiket akışı (çakışma yaratmadan)
B2B senaryosu — doküman/whitepaper yayını
- •Whitepaper publish → CRM kampanya tetik + nurturing
- •Slack → satış ekibine “yeni asset” bildirimi
- •Landing revalidate + dönüşüm takibi kontrol notu (Tag Manager süreçleriyle uyum)
Ne yapmalıyım?
- • Otelde kampanya/oda sayfalarını “kritik” ilan et; hedefli revalidate kur.
- • B2B’de asset yayınlarını CRM automation’a bağla.
- • Delete/unpublish için redirect/SEO aksiyonunu otomatikleştir.
- • Her senaryoyu staging’de test et; prod’da deneme yapma.
- • Otomasyonları yılda en az 1 kez (365) gözden geçir.
6. Güvenlik ve Operasyonel Dayanıklılık (Teknik Not)
Webhook endpoint’leri, dış dünyaya açık “tetik kapısı”dır; korunmazsa spam, brute-force veya yanlış tetiklerle sisteminizi bozabilir. Bu yüzden kimlik doğrulama, rate limit ve loglama şarttır. Bu yaklaşımın /tr/yazilim/sunucu-guvenlik içeriğiyle uyumlu şekilde ele alınması gerekir.
Webhook endpoint’ini koruyan minimum paket
- •Secret signature doğrulama (HMAC vb.)
- •IP allowlist (mümkünse)
- •Rate limit (burst kontrolü)
- •Idempotency (aynı event iki kez gelirse güvenli)
- •Log + alert (başarısız tetikler, 401/403/500)
Webhook güvenliği hakkında neler sorulmalı?
Kısa cevap: Secret doğrulama, rate limit, IP kısıtı, loglama ve tekrar denemelere karşı idempotency uygulanmalıdır.
Ne yapmalıyım?
- • Secret doğrulamayı zorunlu yap; geçmeyeni reddet.
- • Rate limit + idempotency ile spam’i engelle.
- • Logları merkezi topla; hata alarmı kur.
- • Endpoint’i staging/prod ayrı yönet.
- • Güvenlik notlarını /tr/yazilim/sunucu-guvenlik ile hizala.
7. Rakip Açığını Kapat: “Event-Driven”i Üretim Kalitesine Taşı
TR’de CMS entegrasyonları çoğu zaman “çek veriyi göster” seviyesinde; webhook tabanlı event-driven otomasyon rehberleri az. Fark yaratan yaklaşım; webhook’u sadece “tetik” değil, gözlemlenebilir ve güvenli bir release mekanizması olarak ele almaktır: doğru event seçimi, doğrulama, log, retry ve idempotency. Bu kalite katmanı eklendiğinde; manuel build/bildirim/eşitleme işleri büyük oranda azalır ve ekip içerik/stratejiye daha fazla odaklanır.
8. CMS Publish Webhook & ISR/CRM/Slack Otomasyon Planlama Şablonunu İndir — Yazılım / Webhooks
CMS Publish Webhook & ISR/CRM/Slack Otomasyon Planlama Şablonunu İndir — Yazılım / Webhooks (v1.0)
Bu şablon; CMS’teki publish/update/delete event’lerini webhook ile dinleyip Next.js revalidation, Slack bildirimleri ve CRM tetiklerini güvenli biçimde planlamayı amaçlar. Event seçimi, payload sözleşmesi, endpoint güvenliği ve log/alert katmanını tek dokümanda toplayarak manuel işleri azaltır.
Kim Kullanır?
Teknik lider, ajans teknik ekibi, içerik operasyon yöneticisi.
Nasıl Kullanılır?
- Event türlerini ve hangi içerik tiplerini tetikleyeceğini seçin.
- Payload ve güvenlik (secret/rate limit/ip) sözleşmesini doldurun.
- Revalidation path’leri, Slack/CRM aksiyonları ve log/alert kurallarını planlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Event Envanteri
- ▢ ✅ İçerik tipleri: blog / room / campaign / document / service (seç: ____)
- ▢ ✅ Payload Sözleşmesi:
- ▢ ✅ Hedef Aksiyonlar:
- ▢ ✅ Revalidation Planı:
- ▢ ✅ Güvenlik Katmanı:
- ▢ ✅ Loglama ve Operasyon: Log alanları:
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: CMS, ekosistemin tetikleyicisi olduğunda hız ve tutarlılık artar
Webhook’lar; içerik değişikliğini tek bir panel olayından çıkarıp, Next.js revalidation, CRM tetikleri ve ekip bildirimleri gibi çoklu sistem aksiyonlarına dönüştürür. Doğru kurulduğunda publish→live süresi kısalır, manuel iş azalır ve içerik tutarlılığı artar. Güvenlik ve loglama ile desteklendiğinde ise bu otomasyonlar üretim kalitesini yükseltir.
Bir Sonraki Adım
Publish/update/delete tetiklerini güvenli endpoint’lerle standardize edip revalidation ve bildirim süreçlerini otomatikleştirin.
Sık Sorulan Sorular
CMS webhook nedir, ne işe yarar?▾
Yeni içerik yayınlandığında Next.js’i nasıl tetiklerim?▾
CMS’te yapılan değişiklikleri CRM/Slack gibi sistemlere nasıl iletirim?▾
Otel ve B2B için webhook tabanlı otomasyon örnekleri neler?▾
Webhook endpoint’ini nasıl güvenli hale getiririm?▾
Update event’i neden riskli olabilir?▾
İlgili İçerikler