jekcms yayın API'si n8n'e yalnızca birkaç iş akışı düğümüyle bağlanıyor; medya yüklemelerini yönetiyor, kategorileri ayarlıyor ve yayın takviminize uyuyor. Bu makale düğüm yapılandırmasını olduğu gibi paylaşıyor: istek formatı, kimlik doğrulama, hata yönetimi ve anında/zamanlanmış/taslak yayın arasındaki tercih dengesi.
Yayın ucu POST /api/v1/webhook/publish. İki kardeşi var: webhook/draft ve webhook/schedule. Gönderdiğiniz JSON şu alanları alır: title, content, author_id, category, featured_image (bir adres) ve zamanlama kullanıyorsanız ISO 8601 biçiminde scheduled_at. API anahtarı X-API-Key başlığına yazılır ve api_tokens tablosundan doğrulanır. Yazı oluşunca uç, yeni yazının kimliğini ve genel adresini döner.
Minimal n8n İş Akışı Yapısı
n8n'de çalışan en küçük akış dört düğümdür. Bir HTTP Request kaynak içeriği çeker: OpenAI, bir RSS beslemesi ya da kendi kaynağınız. Bir Code düğümü gövdeyi jekcms'in beklediği biçime sokar. İkinci bir HTTP Request webhook ucunu çağırır. Bir IF düğümü de hataları Slack bildirimine veya yeniden deneme kuyruğuna ayırır.
Görseller çok olunca
Burası dikkat isteyen yer. featured_image alanına bir adres verdiğinizde jekcms o dosyayı API isteği sürerken indirir, AVIF'e çevirir ve sunucunuza kaydeder. Kaynak sunucu yavaşsa API isteğiniz de o kadar bekler. Günde çok yazı basıyorsanız görseli önden yükleyin: webhook/media adres alır, webhook/media-base64 dosyayı gömülü kabul eder. Dönen medya referansını yayın çağrısında kullanırsınız, böylece her yayın harici bir indirmeyi beklemez.
Neler Yanlış Gidebilir
Otomatik bir yayın hattında en sık görülen arıza jekcms API'sinden gelmez. Kaynak içeriği çekerken yaşanan ağ zaman aşımıdır. İş akışını, kaynağın zaman zaman yanıt vermeyeceğini baştan kabul ederek kurun: bu hataları ölümcül saymayın, bir yeniden deneme kuyruğuna ya da Slack bildirimine yollayın. force_duplicate: false varsayılanı sayesinde yeniden denenen bir istek aynı yazının ikinci kopyasını açamaz, bu yüzden n8n'in yeniden denemesini başında beklemeden çalıştırabilirsiniz.
Tam n8n Düğüm Yapılandırması
Yayın çağrısının HTTP Request ayarları aşağıda. Content-Type başlığı application/json olmalı. API anahtarını her zaman X-API-Key başlığına yazın, adresin sorgu kısmına değil: sorgu kısmı sunucunun erişim kayıtlarına düşer.
// n8n HTTP Request Dugum Ayarlari
Method: POST
URL: https://siteniz.com/api/v1/webhook/publish
Authentication: None (baslik ile yonetilir)
Headers:
X-API-Key: {{ $credentials.jekcmsApiKey }}
Content-Type: application/json
Body (JSON):
{
"title": "{{ $json.title }}",
"content": "{{ $json.content }}",
"author_id": 2,
"category": "{{ $json.category }}",
"featured_image": "{{ $json.image_url }}",
"image_alt_text": "{{ $json.image_alt }}"
}
IF Düğümü ile Hata Yönetimi
API çağrısından sonraki IF düğümü {{ $json.success }} alanına bakar. Hata varsa dal, yazının başlığını ve hata mesajını Slack'e gönderir. 409 yinelenen yanıtını ayrı bir dala alıyoruz: kaydediyor ama bildirim göndermiyor. Bir içerik yığınını yeniden işlerken yinelenen çıkması zaten beklenir.
Zamanlama ve Yayınlama Sıklığı
jekcms, webhook API üzerinden üç yayınlama modunu destekler:
- Taslak:
webhook/draft. Yazı kaydedilir ama panelden biri okuyup yayınlayana kadar görünmez. Yeni bir iş akışında ya da güvenmediğiniz bir kaynakta buradan başlayın; kimse bakmadan hiçbir şey canlıya çıkmaz. - Zamanlanmış:
webhook/schedule, yanında ISO 8601 biçimindescheduled_at(örneğin2026-03-01T09:00:00+03:00). jekcms yazıyı o saatte açar. Kaynağa güveniyorsanız ve her yazıyı tek tek okumadan düzenli bir takvim istiyorsanız uygundur. - Anında:
webhook/publish. Yazı, API çağrısı başarılı olduğu anda canlıdır; arada okuma adımı yoktur. Kaynak hatalıysa ya da markanıza uymuyorsa siz görmeden yayımlanır. Bu moda, iş akışı taslak veya zamanlanmış yayınla kendini kanıtladıktan sonra geçin.
Karar sizin. jekcms bir onay kuyruğunu zorunlu tutmaz, ama atlamanın riskini de saklamaz. Çoğu ekip için her şeyi taslak ya da zamanlanmış yayından geçirmek, hat oturduktan sonra bile daha iyi bir alışkanlık.
SEO tarafında yazıları tek seferde boşaltmıyoruz. Code düğümünde ardışık zaman damgaları üretip yayınları gün içine eşit aralıklarla dağıtıyoruz.
Kategori ve Etiket Otomasyonu
API kategoriyi kimlikle değil adıyla alır. Kategori yoksa jekcms adından bir bağlantı adresi türetip kendisi açar. Etiketler de aynı: tags alanına adlardan bir dizi verirsiniz. Böylece n8n iş akışınızın sitedeki kategori kimliklerini bilmesine gerek kalmaz; kaynak içerikteki adı geçirir, bulmayı ya da oluşturmayı jekcms'e bırakırsınız.
Webhook İmzalama
jekcms'in webhook uçlarını n8n'in kendisi olmayan, başka bir yerden olayları aktaran bir otomasyondan çağırıyorsanız, jekcms gelen bir X-Webhook-Signature başlığını doğrulayabilir: paylaşılan bir sırra karşı hesaplanan bir HMAC-SHA256 imzası. Bu tam bir imzalama/doğrulama çerçevesi değil, tek bir doğrulama katmanıdır; yükün paylaşılan sırrı bilen biri tarafından gönderildiğini ve iletim sırasında değiştirilmediğini teyit eder.
- Yalnız metinden oluşan bir yazı genelde bir saniyenin çok altında yayımlanır.
- Bir
featured_imageURL'si geçirmek, jekcms'in dosyayı getirmesi, AVIF'e dönüştürmesi ve saklaması için zaman ekler: bunun birkaç saniye sürmesini bekleyin, yavaş kaynak sunucularda veya büyük görsellerde daha fazla. - Hız sınırı: istemci IP'si başına saatte 100 istek.
API_RATE_LIMITile değiştirilir; sınır aşılınca API 429 döner.
Yeniden Deneme Stratejisi ve Idempotency
Ağ hataları herhangi bir otomatikleştirilmiş hatta kaçınılmazdır, bu yüzden bir yeniden deneme stratejisini bilinçli olarak kurmaya değer.
force_duplicate: false varsayılanıyla aynı isteği iki kez göndermek iki yazı üretmez. n8n başarısız sandığı bir isteği yeniden dener ve yazı ilk denemede zaten oluşmuşsa, API ikinci kopyayı açmak yerine 409 döner. Bu yüzden n8n'in kendi yeniden deneme ayarını (Settings > Retry on Fail) birkaç deneme ve aralarında kısa bir bekleme ile açabilirsiniz; yinelenen içerik çıkmaz.
Görsel ağırlıklı akışlarda yavaş bir kaynak sunucu yanıt süresini on saniyenin üzerine çıkarabilir. HTTP Request düğümünün zaman aşımını buna göre yükseltin ve birkaç yeniden denemeye izin verin.
API tarafındaki yinelenen koruması ile iş akışı tarafındaki otomatik yeniden deneme bir araya gelince hattınız geçici hatalardan kendi başına çıkar. Yeniden denemenin çözemediği tek durum, kalıcı olarak erişilemeyen bir kaynak adresidir. Onları sonsuza kadar denemek yerine elle bakılacak bir listeye alın.