WhatsApp Otomasyonu Nasıl Kurulur?

WhatsApp otomasyonu, WhatsApp Business API ile Meta geliştirici hesabı ve webhook yapılandırması üzerinden kurulur. Süreç, CRM sistemleriyle veri akışını standartlaştırır.

WhatsApp otomasyonu, işletmelerin müşteri iletişim süreçlerini ölçeklendirmek, destek maliyetlerini düşürmek ve 7/24 kesintisiz operasyon yürütmek amacıyla WhatsApp Business API (Cloud API veya On-Premises API) altyapısını sistemlerine entegre etme sürecidir. Bu kılavuz, teknik karar vericiler, operasyon yöneticileri ve yazılım ekipleri için sıfırdan canlıya alma adımlarını, webhook mimarisini, CRM veri eşlemelerini, şablon onay mekanizmalarını ve Meta politika uyumluluğunu kapsamlı bir teknik çerçevede ele alır.

WhatsApp Otomasyonu İçin Teknik Ön Koşullar ve Hazırlık Süreci

Kurumsal bir WhatsApp otomasyonu kurgulamadan önce, Meta ekosistemi içerisindeki idari gereksinimlerin ve yasal standartların eksiksiz tamamlanması gerekir. Standart WhatsApp Business mobil uygulaması, eşzamanlı çoklu kullanıcı desteği, programatik tetikleyiciler ve veri tabanı entegrasyonları konusunda yetersiz kalır. Ölçeklenebilir bir otomasyon altyapısı için doğrudan Meta Cloud API veya resmi bir İş Çözümü Sağlayıcısı (BSP - Business Solution Provider) aracılığıyla sunulan WhatsApp Business API kullanılmalıdır.

Hazırlık aşamasında yapılacak teknik veya idari hatalar, projenin ilerleyen safhalarında erişim belirteçlerinin iptal edilmesine, mesajlaşma limitlerinin düşürülmesine veya numaranın tamamen engellenmesine (ban) yol açabilir. Bu nedenle hazırlık süreci; işletme doğrulaması, tahsis edilecek telefon numarasının durumu ve veri koruma mevzuatına uyum olmak üzere üç ana eksende yürütülmelidir.

Onaylı Bir Meta Business Manager Hesabı Yapılandırması

WhatsApp Business API erişimi, doğrudan kurumsal bir Meta Business Manager (İşletme Yöneticisi) hesabı üzerinden yönetilir. Bireysel Facebook hesapları üzerinden kurulan bağlantılar, kurumsal erişim belirteci üretiminde ve faturalandırma süreçlerinde yetki karmaşasına neden olur. İşletme Yöneticisi panelinde "Güvenlik Merkezi" sekmesi altında yer alan "İşletme Doğrulaması" (Business Verification) adımı zorunludur.

Doğrulama sürecinde Meta; resmi şirket unvanını, açık adresini ve işletmeye ait telefon numarasını gösteren resmi belgeleri (vergi levhası, ticaret odası faaliyet belgesi veya şirket adına kesilmiş güncel bir fatura) talep eder. Yüklenen belgelerdeki bilgilerin, Business Manager profilindeki detaylarla harfiyen eşleşmesi kritik önem taşır. Doğrulanmamış hesaplar, günlük yalnızca 250 tekil kullanıcıya mesaj gönderebilen kısıtlı bir geliştirme ortamında çalışabilir; işletme doğrulaması tamamlandığında bu limit kademeli olarak 1.000, 10.000, 100.000 ve sınırsız konuşma seviyelerine (Tier) yükseltilir.

İşletme Numarasının Seçimi ve Meta Doğrulama Adımları

WhatsApp Business API altyapısına bağlanacak telefon numarasının, o anda herhangi bir standart WhatsApp veya WhatsApp Business mobil uygulamasında aktif olmaması şarttır. Mevcut bir numara API'ye taşınacaksa, öncelikle mobil uygulamadaki hesap ayarları üzerinden "Hesabı Sil" işlemi gerçekleştirilmelidir. Yalnızca uygulamanın telefondan kaldırılması yeterli değildir; numaranın Meta veri tabanındaki oturumunun tamamen sonlandırılması gerekir.

Seçilen numara sabit hat (sanal santral/VoIP) veya standart GSM numarası olabilir. Doğrulama aşamasında Meta, numaraya 6 haneli bir OTP (Tek Kullanımlık Şifre) gönderir. Sabit hatlar tercih edilecekse, santralin IVR (sesli yanıt sistemi) menüsünün geçici olarak devre dışı bırakılması veya gelen çağrının doğrudan bir operatöre aktarılması sağlanmalıdır; aksi takdirde Meta'nın otomatik sesli doğrulama araması IVR menüsünü aşamayarak doğrulama başarısızlıkla sonuçlanır.

KVKK ve Açık Rıza (Opt-in) Süreçlerinin Hukuki Altyapısı

WhatsApp otomasyonu, doğrudan uçtan uca şifreleme ve kişisel veri işleme süreçlerini barındırdığından, 6698 sayılı KVKK ve Avrupa Birliği Genel Veri Koruma Tüzüğü (GDPR) kapsamında açık rıza (opt-in) mekanizmasına bağlanmalıdır. İşletmeler, kullanıcıların açık ve doğrulanabilir rızasını almadan WhatsApp üzerinden outbound (giden) mesajlaşma başlatamaz.

Opt-in toplama işlemi web sitesi kayıt formlarındaki işaretleme kutuları (checkbox), SMS onayları, e-posta bülten abonelikleri veya fiziksel sözleşmeler aracılığıyla gerçekleştirilebilir. Onay metninde, kullanıcının WhatsApp üzerinden hangi tür iletileri (sipariş bildirimi, fatura, pazarlama vb.) alacağı açıkça belirtilmelidir. Açık rıza kaydı bulunmayan kullanıcılara iletilen şablon mesajlar, kullanıcıların numarayı "Spam" olarak raporlamasına yol açar; bu durum numaranın Kalite Puanı'nı (Quality Rating) düşürerek API erişiminin askıya alınmasıyla sonuçlanır.

Adım Adım WhatsApp Business API Kurulumu

WhatsApp Business API kurulumu, Meta Cloud API'nin kullanıma sunulmasıyla birlikte sunucu barındırma maliyetlerini minimize eden doğrudan bir entegrasyon modeline dönüşmüştür. İşletmeler, doğrudan Meta altyapısında barındırılan REST API uç noktalarını kullanarak dakikalar içinde mesaj iletimine başlayabilir.

Kurulum süreci, Meta Geliştiriciler (Meta for Developers) platformu üzerinde bir uygulama oluşturulması, WhatsApp ürününün bu uygulamaya tanımlanması ve üretim ortamı için yetkilendirilmiş kalıcı bir erişim belirtecinin (Permanent Access Token) üretilmesini içerir. Geçici belirteçler yalnızca 24 saat geçerli olduğundan, operasyonel süreklilik için Sistem Kullanıcısı (System User) mimarisi yapılandırılmalıdır.

1. Meta Geliştirici Hesabı (Developer Account) Oluşturma

Entegrasyonun ilk teknik adımı, developers.facebook.com adresinde kurumsal Facebook hesabı ile oturum açarak bir geliştirici profili oluşturmaktır. Profil oluşturulduktan sonra panelde yer alan "Uygulama Oluştur" (Create App) butonuna tıklanmalıdır.

Açılan sihirbazda uygulama türü olarak "İşletme" (Business) veya "Diğer" seçeneği belirlenir. Uygulama adı kurumsal kimliğe uygun şekilde girildikten sonra, oluşturulan bu uygulamanın önceden doğrulanan Meta Business Manager hesabına bağlanması zorunludur. Yanlış Business Manager eşleşmesi, ilerleyen adımlarda numara tahsisi ve faturalandırma yetkilerinde teknik kilitlenmelere yol açar.

2. WhatsApp Ürününü Uygulamaya Ekleme ve Numara Kaydı

Uygulama kontrol paneline giriş yapıldığında, platformda sunulan ürünler listesinden "WhatsApp" seçeneği bulunarak "Ayarla" (Set Up) butonu ile uygulamaya dahil edilir. Bu işlem, uygulamaya WhatsApp Business Platform API bileşenlerini ve ilgili REST API uç noktalarını otomatik olarak enjekte eder.

İlk yapılandırma ekranında Meta, geliştirme testleri için geçici bir test telefon numarası ve 24 saat geçerli bir test belirteci sağlar. Ancak canlı ortama geçiş için "Adım 2: Telefon Numarası Ekle" bölümünden işletmenin gerçek telefon numarası sisteme kaydedilmelidir. Numara girildikten sonra SMS veya sesli arama yoluyla gelen 6 haneli doğrulama kodu sisteme girilir. Doğrulama tamamlandığında Meta, bu numaraya özel bir Telefon Numarası Kimliği (Phone Number ID) ve WhatsApp İşletme Hesabı Kimliği (WABA ID) atar. Bu iki kimlik parametresi, gönderilecek tüm API isteklerinin gövdesinde ve URL yapısında kullanılacaktır.

3. Sistem Kullanıcısı Atama ve Kalıcı Erişim Belirteci (Token) Üretimi

Meta geliştirici panelinde üretilen standart kullanıcı token'ları güvenlik nedeniyle 24 saat sonra geçersiz hale gelir. CRM veya otomasyon yazılımlarının kesintisiz çalışabilmesi için Meta Business Manager üzerinden bir Sistem Kullanıcısı tanımlanmalı ve süresiz erişim belirteci üretilmelidir.

İşletme Ayarları > Kullanıcılar > Sistem Kullanıcıları sekmesine gidilerek "Yönetici" (Admin) rolüne sahip yeni bir sistem kullanıcısı eklenir. Ardından bu kullanıcıya, oluşturulan WhatsApp uygulaması üzerinde tam kontrol yetkisi atanır. "Varlık Ata" (Assign Assets) adımından sonra "Yeni Belirteç Oluştur" (Generate New Token) butonuna tıklanır. Açılan izin penceresinde şu iki kritik kapsam (scope) mutlaka seçilmelidir:

• whatsapp_business_messaging (Mesaj gönderme ve alma yetkisi)

• whatsapp_business_management (Şablon oluşturma, numara ve hesap ayarlarını yönetme yetkisi)

Üretilen kalıcı erişim belirteci yalnızca bir kez ekranda gösterilir. Bu belirteç güvenli bir ortamda (.env dosyası veya Vault) saklanmalı ve yetkisiz erişimlere karşı korunmalıdır.

Webhook Yapılandırması ve İki Yönlü İletişim Sağlama

WhatsApp otomasyonunun yalnızca tek taraflı bildirim göndermekle sınırlı kalmayıp iki yönlü etkileşimli bir sisteme dönüşmesi, doğru yapılandırılmış bir Webhook mimarisine bağlıdır. Kullanıcıların gönderdiği metinler, buton tıklamaları, konum paylaşımları veya medya dosyaları Meta sunucuları tarafından anlık JSON payload paketleri halinde işletmenin tanımladığı Webhook URL'ine iletilir.

Webhook altyapısı kurulurken en sık karşılaşılan teknik problem, sunucu yanıt sürelerinin Meta'nın belirlediği sınırları aşmasıdır. Meta sunucuları, fırlattıkları bir webhook isteğine 20 saniye içinde HTTP 200 OK yanıtı alamazsa, bağlantının koptuğunu varsayar ve aynı isteği üstel geri çekilme (exponential backoff) algoritmasıyla tekrar tekrar gönderir. Bu durum, veri tabanında mükerrer kayıt oluşmasına ve sunucu kaynaklarının tükenmesine yol açar.

[Kullanıcı WhatsApp İletisi]
          │
          ▼
[Meta Cloud API Sunucuları]
          │ (HTTPS POST / JSON Payload)
          ▼
[İşletme Webhook Uç Noktası (Endpoint)]
   ├─► Anında HTTP 200 OK Yanıtı Ver
   └─► İsteği Asenkron Kuyruğa İt (Redis / RabbitMQ)
          │
          ▼
[Worker Servisleri & CRM Veri Eşleme]

Webhook Uç Noktası (Endpoint) Mimarisi ve Doğrulama (Verification)

Meta'nın webhook isteklerini kabul edebilmesi için hedef sunucunun geçerli bir SSL sertifikasına (HTTPS) sahip olması ve bir doğrulama el sıkışmasını (handshake) başarıyla tamamlaması gerekir. Geliştirici panelinde Webhook URL ve özel olarak belirlenen bir "Verify Token" (Doğrulama Belirteci) girildiğinde, Meta bu adrese bir HTTP GET isteği gönderir.

Meta'nın GET isteği şu sorgu parametrelerini (query parameters) içerir:

• @@CODE0@@: Değeri daima @@CODE1@@ olarak gelir.

• hub.challenge: Meta tarafından üretilen rastgele bir alfasayısal karakter dizisidir.

• hub.verify_token: Geliştirici panelinde tanımladığınız özel parola dizgisidir.

Sunucu tarafındaki kod, gelen @@CODE0@@ değerinin kendi belirlediği gizli anahtarla uyuşup uyuşmadığını doğrulamalı ve uyuşuyorsa gelen @@CODE1@@ değerini ham metin (plain text) olarak ve HTTP 200 durum koduyla geri döndürmelidir. Bu el sıkışma başarıyla sonuçlanmadan webhook aktif hale getirilemez.

{
  "object": "whatsapp_business_account",
  "entry": [
    {
      "id": "WABA_ID_DEGERI",
      "changes": [
        {
          "value": {
            "messaging_product": "whatsapp",
            "metadata": {
              "display_phone_number": "905XXXXXXXXX",
              "phone_number_id": "PHONE_NUMBER_ID"
            },
            "contacts": [
              {
                "profile": {
                  "name": "Kullanici Adi"
                },
                "wa_id": "905XXXXXXXXX"
              }
            ],
            "messages": [
              {
                "from": "905XXXXXXXXX",
                "id": "wamid.HBgL...",
                "timestamp": "1724755200",
                "text": {
                  "body": "Siparis durumumu ogrenmek istiyorum"
                },
                "type": "text"
              }
            ]
          },
          "field": "messages"
        }
      ]
    }
  ]
}

Meta Geliştirici Panelinde Webhook Aboneliklerini Aktifleştirme

El sıkışma tamamlandıktan sonra, Meta geliştirici panelindeki "Webhook Alanları" (Webhook Fields) sekmesinden hangi olayların dinleneceği belirlenmelidir. WhatsApp otomasyonu için temel olarak iki alanın aboneliği aktifleştirilmelidir:

1. messages: Kullanıcılardan gelen tüm gelen iletileri (metin, görsel, ses, buton tıklamaları, hızlı yanıtlar) iletir.

2. message_template_status_update: Gönderilen şablon mesajların onay, ret veya duraklatılma durumlarındaki değişiklikleri bildirir.

Bu abonelikler tamamlandığında, işletme numarasına gelen her mesaj anında yapılandırılan uç noktaya HTTP POST isteği olarak yönlendirilir.

Gelen Verilerin (Payload) Güvenli Bir Şekilde İşlenmesi ve Sunucu Yanıt Süresi

Gelen HTTP POST istekleri doğrudan ana uygulama mantığı içinde senkron olarak işlenmemelidir. Yoğun mesaj trafiği altında CRM sorguları, yapay zeka çıkarımları veya veri tabanı yazma işlemleri sunucu yanıt süresini (latency) artırır.

Doğru mimari yaklaşım, gelen webhook isteğini karşılayan web sunucusunun (API Gateway, Nginx, Node.js, Go veya Python) yükü (payload) alır almaz bir kuyruk kuyruğuna (Redis BullMQ, RabbitMQ, AWS SQS veya Kafka) aktarması ve Meta'ya derhal 200 OK dönmesidir. Arka planda çalışan işçi servisler (worker processes), kuyruktan mesajları asenkron olarak tüketerek CRM eşleştirmelerini, chatbot mantıklarını ve otomatik yanıt üretimlerini gerçekleştirmelidir.

Güvenlik katmanında ise Meta'nın gönderdiği her POST isteğinin başlığında (header) yer alan X-Hub-Signature-256 değeri doğrulanmalıdır. Bu imza, gelen payload verisinin uygulamanın "App Secret" anahtarı ile HMAC-SHA256 algoritması kullanılarak imzalanmış halidir. İmza doğrulaması yapılmayan webhook uç noktaları, dışarıdan sahte veri enjeksiyonuna açık hale gelir.

CRM Sistemleri ile Veri Akışının Standartlaştırılması

WhatsApp otomasyonunun en kritik çıktısı, müşteri iletişim geçmişinin ve talep verilerinin kurumsal CRM (HubSpot, Salesforce, Zoho, Microsoft Dynamics veya şirket içi özel CRM sistemleri) altyapılarına gerçek zamanlı aktarılmasıdır. Standartlaştırılmamış bir veri akışı, müşteri temsilcilerinin mükerrer kayıt açmasına veya müşteri bağlamının kaybolmasına yol açar.

Veri standardizasyonu, WhatsApp API'den gelen ham JSON formatındaki heterojen verilerin (telefon numarası, isim, mesaj kimliği, etkileşim zamanı, medya URL'leri) CRM sisteminin kabul ettiği standart veri modellerine dönüştürülmesi (Data Mapping) işlemidir. Bu yapı, omnichannel (çok kanallı) müşteri deneyiminin omurgasını oluşturur.

API Üzerinden Gelen Mesajların CRM Veritabanına Eşlenmesi

WhatsApp'tan gelen iletilerde birincil tekil anahtar (Primary Key) kullanıcının telefon numarasıdır (wa_id). Gelen mesaj işlenirken CRM veritabanında öncelikle bu telefon numarasıyla eşleşen bir "İletişim Kişisi" (Contact/Lead) sorgulanır.

1. Kayıt Eşleştirme (Identity Resolution): Telefon numarası sistemde mevcutsa, gelen mesaj mevcut kişinin iletişim geçmişi (Timeline/Activity Log) altına yeni bir aktivite olarak eklenir. Numara sistemde kayıtlı değilse, Meta profil adı (profile.name) kullanılarak otomatik olarak yeni bir "Aday Müşteri" (Lead) kartı açılır.

2. Medya Dosyalarının Arşivlenmesi: Kullanıcının gönderdiği ses kayıtları, PDF belgeleri veya görseller Meta sunucularında kalıcı olarak saklanmaz; belirli bir süre sonra silinir. Bu nedenle webhook üzerinden gelen medya ID'si (@@CODE0@@) kullanılarak ilgili dosya Meta Graph API'den @@CODE1@@ isteğiyle indirilmeli, kurumsal bir bulut depolama alanına (AWS S3, Google Cloud Storage) yüklenmeli ve CRM kaydına bu kalıcı URL bağlanmalıdır.

Tetikleyiciler (Triggers) ile Otomatik Yanıt Senaryoları Kurgulama

Veri akışı çift yönlü çalışmalıdır. Yalnızca müşteriden gelen mesajlara yanıt vermek değil, CRM içinde gerçekleşen durum değişikliklerine (Status Changes) bağlı olarak otomatik WhatsApp bildirimleri fırlatmak otomasyonun temel değeridir.

Bu kurgu, CRM üzerinde tanımlanan Webhook Tetikleyicileri (Triggers) ve İş Akışları (Workflows) aracılığıyla yürütülür:

• Sipariş Durumu Değişikliği: E-ticaret veya ERP sisteminde bir sipariş "Kargoya Verildi" statüsüne geçtiğinde, sistem bir webhook fırlatarak WhatsApp API üzerinden müşteriye takip numarası içeren onaylı bir kargo şablon mesajı iletir.

• Terk Edilmiş Sepet Bildirimi: Kullanıcı ödeme adımını tamamlamadığında, 1 saatlik bekleme süresinin ardından dinamik indirim kuponu içeren kişiselleştirilmiş bir mesaj tetiklenir.

• Randevu Hatırlatma: Sağlık veya hizmet sektöründe, randevu saatinden 24 saat önce dinamik interaktif butonlar ("Onaylıyorum", "İptal Et", "Ertele") barındıran bir hatırlatıcı gönderilir. Kullanıcının tıkladığı buton webhook üzerinden geri okunarak CRM'deki randevu statüsü insan müdahalesi olmadan güncellenir.

Omnichannel Müşteri İlişkileri Yönetimi ve Çift Yönlü Senkronizasyon

Gelişmiş otomasyon senaryolarında, chatbot ile müşteri arasındaki konuşma tıkandığında veya kullanıcı doğrudan bir müşteri temsilcisiyle görüşmek istediğinde oturum kesintisiz biçimde canlı destek ekranına devredilmelidir (Human Handoff).

Otomasyon motoru, gelen iletide "yetkili", "temsilci", "canlı destek" gibi anahtar kelimeleri veya NLP niyetlerini (intent) tespit ettiği anda, konuşmanın @@CODE0@@ bayrağını @@CODE1@@ durumuna getirir ve CRM üzerinde ilgili departmana (örneğin Teknik Destek veya Satış) bir destek talebi (Ticket) atar. Temsilcinin CRM panelinden yazdığı yanıtlar, REST API aracılığıyla doğrudan müşterinin WhatsApp ekranına iletilir. Temsilci görüşmeyi sonlandırdığında, bot modu tekrar aktif hale getirilerek otomasyon döngüsü kaldığı yerden devam eder.

Şablon Mesajlar (Message Templates) ve Meta Onay Süreci

Meta, WhatsApp ekosistemini spam iletilerden korumak ve kullanıcı deneyimini yüksek tutmak amacıyla katı bir mesajlaşma çerçevesi uygular. İşletmeler, müşterilerine istedikleri zaman serbest metin formatında mesaj gönderemezler. İletişim kuralları, "24 Saatlik Müşteri Hizmetleri Penceresi" (Customer Service Window) mantığına dayanır.

Müşteri işletmeye bir mesaj gönderdiğinde 24 saatlik bir oturum başlar. Bu 24 saatlik süre boyunca işletme, müşteriye herhangi bir format kısıtlaması olmadan serbest metin, ses, görsel veya interaktif mesaj gönderebilir. Ancak 24 saatlik süre dolduğunda veya iletişimi ilk başlatan taraf işletme olduğunda (Outbound), yalnızca Meta tarafından önceden incelenip onaylanmış Şablon Mesajlar (Message Templates) kullanılabilir.

Pazarlama, Hizmet (Utility) ve Doğrulama Kategorilerinde Şablon Kuralları

Meta, şablon mesajları kullanım amaçlarına göre üç ana kategoriye ayırır ve ücretlendirmeyi bu kategoriler üzerinden konuşma tabanlı (Conversation-Based Pricing) olarak belirler:

1. Pazarlama (Marketing) Şablonları: Ürün tanıtımları, indirim kuponları, kişiselleştirilmiş teklifler, sepet hatırlatmaları ve doğrudan satış odaklı tüm iletileri kapsar. Bu şablonların maliyeti diğer kategorilere göre daha yüksektir ve kullanıcıların bu mesajları kolayca devre dışı bırakabilmesi için "Abonelikten Çık" (Opt-out) butonu barındırması zorunludur.

2. Hizmet / İşlem (Utility) Şablonları: Kullanıcının gerçekleştirdiği doğrudan bir işleme istinaden gönderilen bilgilendirme iletileridir. Sipariş onayları, kargo takip bildirimleri, hesap ekstresi güncellemeleri, randevu hatırlatmaları ve fatura bildirimleri bu kategoridedir. Reklam veya tanıtım unsuru içeremezler.

3. Kimlik Doğrulama (Authentication) Şablonları: Tek kullanımlık şifreler (OTP), iki adımlı doğrulama (2FA) kodları ve hesap kurtarma bağlantılarını içerir. Bu şablonlar son derece katı biçimlendirme kurallarına tabidir; butonlar yalnızca "Kodu Kopyala" veya "Tek Tıkla Doğrula" işlevlerini içerebilir, URL parametreleri ve metin gövdesi üzerinde herhangi bir pazarlama ifadesi bulunamaz.

{
  "name": "siparis_kargo_guncelleme",
  "language": "tr",
  "category": "UTILITY",
  "components": [
    {
      "type": "HEADER",
      "format": "TEXT",
      "text": "Siparişiniz Yola Çıktı!"
    },
    {
      "type": "BODY",
      "text": "Sayın {{1}}, {{2}} numaralı siparişiniz {{3}} kargo firmasına teslim edilmiştir. Takip kodunuz: {{4}}.",
      "example": {
        "body_text": [
          ["Ahmet Yılmaz", "TR-89421", "Yurtiçi Kargo", "YK123456789"]
        ]
      }
    },
    {
      "type": "BUTTONS",
      "buttons": [
        {
          "type": "URL",
          "text": "Kargom Nerede?",
          "url": "https://ornek-lojistik.com/takip/{{1}}",
          "example": ["YK123456789"]
        }
      ]
    }
  ]
}

Değişken Parametrelerin (Variables) Yapılandırılması ve Şablon Reddi Nedenleri

Şablonlar oluşturulurken dinamik alanlar @@CODE0@@, @@CODE1@@ gibi çift süslü parantezlerle tanımlanır. Meta'ya şablon onaya gönderilirken bu değişkenlerin içine gelecek değerlere dair gerçekçi örnek veriler (Sample Values) sunulması zorunludur. Örnek veri girilmeyen veya anlamsız test dizgileri ({{1}} = "asdasd") içeren şablonlar yapay zeka denetleyicileri tarafından anında reddedilir.

Şablon reddine yol açan yaygın hatalar şunlardır:

• Kategori Uyuşmazlığı: Bir kargo bildirim şablonunun sonuna "Ayrıca web sitemizdeki %20 indirimi kaçırmayın!" gibi pazarlama ifadesi eklenmesi ve şablonun "Utility" olarak gönderilmesi. Meta bu şablonu reddeder veya otomatik olarak daha yüksek tarifeli "Marketing" kategorisine geçirir.

• Yazım ve İmla Hataları: Ciddi dilbilgisi hataları, aşırı emoji kullanımı, tamamı büyük harfle yazılmış metinler veya yanıltıcı formatlar red sebebidir.

• Değişken Konumlandırma Hataları: Şablonun yalnızca değişkenlerden oluşması (örneğin sadece {{1}} {{2}}) veya değişkenlerin şablonun en başında/en sonunda açıkta bırakılması güvenlik politikalarına aykırıdır.

24 Saatlik Müşteri Hizmetleri Penceresi ve Oturum Tabanlı Ücretlendirme

WhatsApp Business API fiyatlandırma modeli, mesaj başına değil, 24 saatlik oturum/konuşma (Conversation) bazlı işletilir. İşletme bir şablon gönderdiğinde veya müşterinin başlattığı konuşmaya serbest yanıt verdiğinde 24 saatlik bir konuşma penceresi açılır. Bu pencere içerisinde işletme ile müşteri arasındaki mesajlaşmalar ek bir konuşma ücreti doğurmaz.

Ücretlendirme, konuşmanın kim tarafından başlatıldığına (Kullanıcı Başlatmalı / İşletme Başlatmalı) ve şablonun kategorisine (Pazarlama, Hizmet, Kimlik Doğrulama) göre ülkesel bazda farklı tarifelendirilir. Maliyet optimizasyonu sağlamak isteyen işletmeler, müşteriyi konuşmayı başlatmaya teşvik eden web widget'ları, QR kodlar veya "WhatsApp'a Tıkla" (Click-to-WhatsApp) reklamları kullanarak kullanıcı başlatmalı (daha düşük maliyetli) konuşma pencereleri açmalıdır.

Operasyonel Riskler, Güvenlik ve Kalite Takibi

WhatsApp API altyapısına geçiş yapmak, işletmelere sınırsız ve kontrolsüz bir mesajlaşma serbestisi tanımaz. Meta, kullanıcı deneyimini korumak amacıyla son derece katı anti-spam algoritmaları ve itibar takip sistemleri çalıştırır. Teknik olarak kusursuz çalışan bir otomasyon, hatalı operasyonel stratejiler nedeniyle numaranın kalıcı olarak engellenmesine ve iş süreçlerinin durmasına sebep olabilir.

Operasyonel risk yönetimi; mesaj gönderim hız sınırlarının (Rate Limits), telefon numarasının Kalite Puanı'nın (Quality Rating) ve hata yakalama (Error Handling) mekanizmalarının sürekli izlenmesini gerektirir.

Meta Ticaret Politikaları İhlalinde Numara Engelleme (Ban) Riskleri

Meta Ticaret İlkeleri (Commerce Policy) ve WhatsApp İşletme Politikası, platform üzerinden satışı veya tanıtımı yasaklanmış ürün ve hizmet kategorilerini açıkça belirler. Tütün mamulleri, alkol, reçeteli ilaçlar, takviye gıdalar, kumar, kripto para spekülasyonları, yetişkin içerikler ve üçüncü taraf dijital telif ihlalleri doğrudan engelleme sebebidir.

Politika ihlalleri iki şekilde gerçekleşir:

1. Şablon İnceleme Engeli: Yasaklı bir sektöre ait anahtar kelimeler içeren şablonlar onaylanmaz.

2. Kullanıcı Geri Bildirim Engeli: Kullanıcıların mesajı "Spam Olarak Bildir" veya "Engelle" butonlarına tıklaması. Belirli bir zaman diliminde gelen engelleme oranının toplam gönderime oranı kritik eşiği (%1-2) aştığında Meta sistemi önce numarayı "Düşük Kalite" (Low Quality) durumuna alır; ihlalin devamı halinde ise API erişimini tek taraflı olarak fesheder.

Mesaj Gönderim Sınırları (Messaging Limits) ve Kalite Puanı Takibi

Meta, işletme numaralarını günlük başlatabilecekleri tekil müşteri konuşma sayısına göre dört farklı Gönderim Seviyesine (Messaging Tier) ayırır:

• Tier 1: 24 saatlik süre içinde 1.000 tekil müşteriye mesaj başlatma hakkı.

• Tier 2: 24 saatlik süre içinde 10.000 tekil müşteriye mesaj başlatma hakkı.

• Tier 3: 24 saatlik süre içinde 100.000 tekil müşteriye mesaj başlatma hakkı.

• Tier 4: Sınırsız sayıda tekil müşteriye mesaj başlatma hakkı.

[Tier 1: 1.000/gün]
        │
        ▼ (Yüksek Kalite Puanı + Limit Doluluğu: 7 Gün)
[Tier 2: 10.000/gün]
        │
        ▼ (Yüksek Kalite Puanı + Limit Doluluğu: 7 Gün)
[Tier 3: 100.000/gün]
        │
        ▼ (Yüksek Kalite Puanı + Limit Doluluğu: 7 Gün)
[Tier 4: Sınırsız]

Bir üst seviyeye geçebilmek için mevcut seviye limitinin en az %50'sinin aktif olarak kullanılması ve telefon numarasının Kalite Puanı'nın "Yüksek" (Yeşil) veya "Orta" (Sarı) seviyede tutulması gerekir. Numara kalitesi "Düşük" (Kırmızı) seviyeye düştüğünde, işletmeye 7 günlük bir iyileştirme süresi (Flagged State) tanınır. Bu süre zarfında spam şikayetleri düşürülemezse gönderim limiti bir alt seviyeye düşürülür ve şablon onayları durdurulur.

Hata Yakalama (Error Handling) ve API Hız Sınırları (Rate Limiting)

Meta Cloud API, tek bir telefon numarası için saniyede ortalama 80 mesaja (Throughput Limit) kadar istek kabul eder. Kitlesel pazarlama kampanyalarında binlerce istek aynı anda API'ye gönderilirse, Meta sunucuları HTTP 429 Too Many Requests (Rate Limit Exceeded) hatası döndürür.

Yazılım mimarisinde bu riskleri engellemek için şu mekanizmalar kurulmalıdır:

• Leaky Bucket / Token Bucket Algoritmaları: API isteklerini saniyede 50-70 istek seviyesinde sınırlayarak kuyruktan kontrollü fırlatmak.

• Üstel Geri Çekilme (Exponential Backoff): @@CODE0@@ veya geçici @@CODE1@@ sunucu hataları alındığında, sistemi kilitlemek yerine isteği 2, 4, 8, 16 saniye gibi artan aralıklarla yeniden denemek (Retry Mechanism).

• Idempotency (Mükerrerlik Önleme): Ağ kopmalarında aynı mesajın müşteriye iki kez gitmesini engellemek için her mesaja özel bir benzersiz istemci referans ID'si (Client Reference ID) tanımlamak.