TL;DR: browser-use, Playwright aracılığıyla Chrome'u headless modda çalıştırıyor. WhatsApp headless oturumları tespit edip hesabı engelliyor. 30 günde 12 yasak ve 47 bozuk oturumun ardından tüm sistemi Whapi.Cloud'a yapılan 10 satırlık bir REST çağrısıyla değiştirdim. Tarayıcı katmanını tamamen atlayın. Düzgün bir API bağlantısı; kimlik doğrulama, yeniden bağlanma ve teslimat onayını — tarayıcı otomasyonunun yarattığı bakım yükü olmadan — kendisi yönetir.
browser-use Deposunu GitHub'da Bulduğum Gün
browser-use deposu bir kısayol gibi görünüyordu: bir LLM'i tarayıcıya yönlendir, WhatsApp Web'i açmasını söyle, mesaj gönder. API onay süreci yok, aylık abonelik yok. Test mesajım 30 saniyeden kısa sürede iletildi.
Bir e-ticaret yan projesi için bildirim botu kuruyordum: ödeme sırasında onay veren müşterilere sipariş onayları ve kargo uyarıları göndermek için. Resmi WhatsApp Business Platform, zaman alan Meta iş doğrulaması gerektiriyordu. Whapi.Cloud gibi yönetilen API sağlayıcıları, doğrulama kuyruğu olmadan WhatsApp web oturum soketleri üzerinden bağlanıyor ve kurulum on dakikadan az sürüyor. Bunu henüz bilmiyordum. browser-use'u üç gün önce GitHub'da otomasyon örnekleri ararken bulmuştum ve birisi issues bölümünde onu WhatsApp Web'e karşı çalıştırdığından söz etmişti.
İlk yerel test mükemmel çalıştı. LLM ajanı WhatsApp Web'i açtı, sohbeti buldu, mesajı yazdı ve gönderdi. Bir sarmalayıcı (wrapper) yazdım, ayda $10'luk bir DigitalOcean damlasına (droplet) deploy ettim ve abonelik ücretinden kurtulduğum için oldukça zekice bir şey yaptığımı düşündüm. Bu dört gün sürdü.
Beşinci gün pipeline mesaj iletmeyi durdurdu. Loglarda istisna yoktu. Tarayıcı başlıyordu, ajan çalışıyordu ama hiçbir şey gönderilmiyordu. SSH ile VPS'e bağlandım ve WhatsApp Web'in QR kodu gösterdiğini gördüm. Süreç headless modda çalışırken oturum sona ermişti. Telefonumdan taradım, mesajlar bir gün daha gitti, ardından oturum yeniden sona erdi.
QR kodu her 24–48 saatte bir sürüyor ve oturum herhangi bir uyarı vermeden ölüyordu. «Otomatik» pipeline'ım her an yanında telefonuyla hazır duran bir insan gerektiriyordu.
browser-use'un GitHub issues sayfasını defalarca inceledim. Oturum kalıcılığı hakkında düzinelerce konu. İnsanlar tarayıcı bağlamını diske kaydetmeyi, ilk tarama için headless olmayan modda çalıştırmayı, localStorage durumunu bir dosyaya kaydetmeyi öneriyordu. Hepsini denedim. Oturum ömürleri biraz uzadı. WhatsApp otomatik tarayıcıyı tespit edip oturumları sunucu tarafında sonlandırıyordu.
WhatsApp Neden browser-use'u Tespit Eder: Parmak İzi Zinciri
browser-use, Playwright üzerinde çalışır ve Playwright headless Chrome çalıştırır. WhatsApp tarayıcı katmanının parmak izini alıp özellikle headless oturumları işaretler. Tespit, mesaj içeriğini değil çalışma ortamını hedef alır.
Tespit aynı anda birkaç katmanda çalışır. Birincisi: navigator.webdriver. Headless bir Playwright oturumunda bu JavaScript özelliği varsayılan olarak true olarak ayarlanır. WhatsApp Web bunu okur. Gerçek bir kullanıcının tarayıcısı false döndürür. Bu tek özellik, güvenilir ve kontrol edilmesi ucuz bir bot sinyalidir; WhatsApp bunu yıllardır kontrol ediyor.
Headless Chrome oturumunda navigator.webdriver = true: WhatsApp bu özelliği bağlantıda okur ve tarayıcı parmak izinde en belirgin otomatik oturum sinyallerinden biridir.
Bu tek özelliğin ötesinde parmak izi daha derine iner. Bulut VPS üzerinde çalışan headless bir örneğin WebGL oluşturucu dizesi, tüketici bir dizüstü bilgisayarın GPU sürücüsü adından farklıdır. Bağlantı zamanlama kalıpları da ayrışır. WhatsApp Web arayüzünde gezinen bir LLM ajanı milisaniye düzeyinde makineye özgü düzenli gecikmeler üretir; bir kişiyi her seferinde tam olarak aynı sayıda milisaniyede seçer. Kaydırma davranışı, tıklama olayı zamanlaması, DOM etkileşim dizileri: bu kalıplar yıllardır birçok platformda bot tespitinde kullanılmaktadır ve WhatsApp da bir istisna değildir.
browser-use, parmak izi sinyallerini maskelemek için stealth eklentileriyle headless olmayan modda çalıştırılabilir. Her ikisini de denedim. Bulut sunucusunda headless olmayan mod, sanal ekran öykünücüsü olan Xvfb gerektirir. Bu, bakımı gereken başka bir servis ve başka bir hata noktası ekler. Stealth eklentileri bazı özellikleri yamalar ama hepsini değil. WhatsApp'ın tespit güncellemeleri topluluk eklentilerinden daha hızlı güncellenir: 2025'in başında işe yarayan yaklaşımlar, browser-use ve Playwright GitHub issues sayfasındaki raporlara göre 2025'in ortasına kadar kısmen yeniden tespit edildi.
Ayrıca WhatsApp'ın sunucu tarafı yaptırımlarının gerçekte neyi izlediğine ilişkin ayrıntılı bir döküm için Whapi.Cloud'un hesap yasağından kaçınma rehberini okuyabilirsiniz. Kalıplar yalnızca parmak izleriyle değil, yeni numara davranışı ve hacim artışlarıyla da ilgilidir. Ancak browser-use için özellikle parmak izi sorunu temel olandır ve uygulama katmanından yama uygulamak kazanılması mümkün olmayan bir oyundur.
Zincir şöyle işler: browser-use, Playwright'ı çalıştırır; WhatsApp, Playwright'ı tespit eder; hesabınız ortadan kalkar. Sorun altyapı düzeyinde var olduğu için temiz bir atlatma yolu yoktur. WhatsApp, headless Chrome'un parmak izini insan tarayıcılarından farklı alır ve engeller. navigator.webdriver'ı yamalamanız sizi tespit listesinde bir adım aşağı taşır, listeden çıkarmaz.
30 Günün Özeti: 12 Yasak, 47 Bozuk Oturum, Sıfır Kararlı Pipeline
Üretimde 30 gün boyunca browser-use'u WhatsApp Web'e karşı çalıştırırken 12 hesap yasağı, manuel kurtarma gerektiren 47 oturum ve yaklaşık 23 saatlik bakım süresi kaydettim. Log iyimser başlıyor.
1. Hafta sorunsuz geçti. Oturumlar iki kez sona erdi, her seferinde telefonumdan QR taradım ve yaklaşık 200 mesaj iletildi. Küçük rahatsızlıkları olan işe yarar bir şeyim olduğunu düşündüm.
2. Hafta ilk yasakla başladı. Kullandığım telefon numarası WhatsApp'tan geçici bir kısıtlama aldı. Sebep belirtilmedi, yalnızca Hizmet Şartları ihlali bildirimi. Kısıtlama 24 saat sonra kaldırıldı. Bir konut proxy hizmeti ekledim ve gönderme hızını düşürdüm.
Proxy'ler beş gün yardımcı oldu. Sonra ikinci bir yasak, bu kez 48 saat. Üçüncü bir numara kaydettim. Oturum kesintileri günlük hale geldi, bazen günde birden fazla; proxy, tarayıcı oturum durumunu karıştıran bağlantı gecikmesi getirdi. Her sabah başka her şeyden önce VPS loglarını kontrol ediyordum.
21. Gün: bir hafta içinde üçüncü yasak. Artık her yasağı gelmeden beklediğim için kayıtlı ve hazır bekleyen bir yedek telefon numaram vardı.
Dördüncü haftaya gelindiğinde «session manager» adını verdiğim şeyi oluşturmuştum. Pratikte: üstel geri çekilmeli (exponential backoff) yeniden deneme döngüsü, /health uç noktası, oturum düşme uyarıları için Telegram botu ve her yasak bir sonrakini tetiklemekten kaçınmak için belirli bir yeniden kimlik doğrulama dizisi gerektirdiğinden sürekli başvurduğum bir kurtarma prosedürü. Otomasyon artık çalışmak için aktif izleme gerektiriyordu.
Son arıza, bir kargo onayı grubunun ortasında gece saat 02:00'de gerçekleşen oturum düşmesiydi. Kırk müşteri sipariş durum güncellemelerini bekliyordu. Oturum düşmüştü, yeniden deneme döngüsü hiç mesaj göndermeden tüm girişimleri tükenmişti ve Telegram uyarım ben uyurken tetiklenmişti. Boş bir kuyruk ve 40 iletilmemiş bildirimle uyandım.
30 günde yirmi üç saatlik bakım felaket gibi gelmiyor; ta ki bunların tamamının gece ve hafta sonlarına dağıldığını fark edene kadar. Oturumlar öngörülebilir bir programa göre bozulmaz. Kampanyalar sırasında, sipariş yoğun saatlerinde ve siz uyurken bozulur.
browser-use WhatsApp Kodu Üretimde Gerçekte Nasıl Görünür
Üretimde çalıştırdığım browser-use WhatsApp kurulumu burada. Tek bir mesaj gönderme girişimi için otuz bir satır; hata işleme bloğu, asıl gönderme mantığından daha uzun.
Bu temel gönderme işlevidir. Yeniden başlatmada QR taramasını atlamak için kaydedilmiş bir tarayıcı bağlamını yeniden kullanır.
import asyncio
import os
from browser_use import Agent, Browser, BrowserConfig
from browser_use.browser.context import BrowserContextConfig
from langchain_openai import ChatOpenAI
SESSION_FILE = "/tmp/whatsapp_session.json"
async def send_whatsapp_message(phone: str, message: str) -> bool:
browser = Browser(
config=BrowserConfig(
headless=True, # headless = detectable by WhatsApp
chrome_instance_path="/usr/bin/chromium",
)
)
context_config = BrowserContextConfig(
save_storage_state=SESSION_FILE,
storage_state=SESSION_FILE if os.path.exists(SESSION_FILE) else None,
)
agent = Agent(
task=(
f"Open https://web.whatsapp.com. "
f"If a QR code is visible, raise an error -- session expired. "
f"Search for contact {phone}, open the chat, "
f"type '{message}', and click Send."
),
llm=ChatOpenAI(model="gpt-4o"),
browser=browser,
browser_context_config=context_config,
)
try:
await agent.run(max_steps=20)
return True
except Exception as e:
os.remove(SESSION_FILE) # force re-auth on next run
raise RuntimeError(f"Send failed: {e}") from e
finally:
await browser.close()Bu işlev tam olarak bir mutlu yolu (happy path) ele alır. CAPTCHA zorluklarını, güncellemeler sonrasında WhatsApp Web DOM düzenindeki değişiklikleri, sunucudan gelen hız sınırı yanıtlarını, ajanın yanlış kişiyi seçtiği durumu veya LLM'in sohbeti bulmadan adımlarını tükettiği durumu ele almaz.
Bu işlevin etrafındaki oturum kurtarma sarmalayıcısı 15 satır daha yeniden deneme mantığı ekliyor ve yine de biri fiziksel olarak telefonu almadan CAPTCHA zorluğundan veya kalıcı hesap yasağından kurtulamıyor.
Üçüncü haftanın sonunda üretim kurulumu şunları da içeriyordu: beş dakikada bir /health ping'i, hata durumunda Telegram uyarısı, yeniden denemelerde üstel geri çekilme, iletilmemiş mesajlar için ölü-mesaj kuyruğu ve bir yasaktan sonra oturumu yeniden başlatmak için kurtarma betiği. İşte «üretim ölçeğinde WhatsApp için browser-use kullanmanın» gerçek kapsamı bu.
Bu iskelet yapı olmadan temiz bir Python WhatsApp kurulumu çok farklı görünür. Python WhatsApp botu rehberi, numara bağlantısından mesaj teslimatına kadar tüm stack'i kapsar.
browser-use Ne Zaman Gerçekten Mantıklı? (Sadece WhatsApp için Değil)
browser-use, tarayıcı otomasyonu için işe yarar. WhatsApp, bunu uygulamak için en kötü yüzeylerden biridir; çünkü WhatsApp, browser-use'un dayandığı tam çalışma ortamını aktif olarak tespit eder.
browser-use'un iyi çalıştığı kullanım senaryoları:
-
API'siz sitelerde web kazıma: programatik erişim sunmayan ve aktif bot tespiti çalıştırmayan genel sayfalardan yapılandırılmış veri çıkarma.
-
Dahili araç otomasyonu: hedef sistem otomasyonu aktif olarak tespit etmediğinde eski CRM'lerdeki veya dahili portallardaki kurumsal formları doldurma. Değişken düzenlerle çok adımlı iş akışları burada iyi çalışır.
-
Bir yapay zeka ajanının birden fazla siteye göz attığı, veri topladığı ve birleştirilmiş bir çıktı ürettiği araştırma ve çok sayfalı sentez görevleri. Bunu tek bir API karşılamaz; tarayıcı mevcut tek arayüzdür.
WhatsApp URL'de yoksa browser-use büyük ihtimalle makul bir seçimdir.
İki Haftada Üçüncü Yasağımın Ardından Gerçek Bir API'ye Geçtim
İki haftada üçüncü yasağın ardından tarayıcı katmanına yama uygulamayı bıraktım ve farklı bir bağlantı modeli aradım. Whapi.Cloud, tarayıcı yerine web oturum soketleri kullanır — sizin tarafınızda headless Chrome süreci ve tespit edilebilir parmak izi olmadan.
Bağlantı modeli temel farktır. browser-use bir Chrome süreci başlatır, gerçek bir tarayıcı gibi WhatsApp Web'de gezinir ve bu oturumu yeniden başlatmalar arasında korumaya çalışır. Whapi.Cloud, yönetilen altyapıda bağlantıyı protokol katmanında yönetir. Kodunuz bir REST çağrısı yapar. Sizin tarafınızda hiç tarayıcı çalışmadığı için parmak izi alınacak bir tarayıcı yoktur.
İşte 31 satırlık browser-use işlevimin yerini alan kod. Aynı numaraya aynı mesajı gönderir, aynı kullanım senaryosunu 10 satırda çözer:
import requests
WHAPI_TOKEN = "YOUR_TOKEN_HERE"
def send_whatsapp(phone: str, message: str) -> dict:
"""Send a WhatsApp text message via Whapi.Cloud REST API."""
response = requests.post(
"https://gate.whapi.cloud/messages/text",
headers={"Authorization": f"Bearer {WHAPI_TOKEN}"},
json={"to": f"{phone}@s.whatsapp.net", "body": message},
)
response.raise_for_status()
return response.json()
# Usage -- returns message ID and delivery confirmation
result = send_whatsapp("15551234567", "Your order has shipped!")
print(result)Yönetilecek tarayıcı süreci yok. Oturum dosyaları yok. Her sunucu yeniden başlatmada taranacak QR kodu yok. Numara, Whapi.Cloud panosu üzerinden QR tarama yoluyla bir kez bağlandı ve API o tarihten beri canlı. Webhook'lar gelen mesajları yoklama (polling) olmadan gerçek zamanlı olarak iletir. Tam API belgeleri, Python, PHP ve Node.js'te kod örnekleriyle her uç noktayı kapsar.
Geçişten bu yana üç hafta içinde WhatsApp Web, GitHub issues'ta tartışılan birçok tarayıcı otomasyon kurulumunu bozan bir arayüz güncellemesi yayınladı. Whapi.Cloud bağlantısı tarafımda herhangi bir değişiklik olmadan çalışmaya devam etti. Ekibi, WhatsApp protokol değişikliklerini izleyerek sürekli güncellemeler yayınlıyor. WhatsApp kaputun altında bir şeyi değiştirdiğinde altyapıları bunu absorbe ediyor. Tarayıcı otomasyonu çalıştırdığınızda ise her WhatsApp Web güncellemesi sizin acil durumunuz haline gelir.
Aynı Whapi.Cloud bağlantısı yasak, oturum düşmesi veya gece 2 uyarısı olmadan üç hafta boyunca çalıştı. Bakım kaydının tamamı bu: browser-use kurulumunda 12 yasak ve 47 bozuk oturumun gerçekleştiği aynı pencerede sıfır olay. Yönetilen API altyapısı çalışma süresi garantileri sunar. Tarayıcı otomasyonunun güvenilirlik geçmişi şöyle: dün çalıştı.
«browser-use WhatsApp» Arayışıyla Buraya Geldiyseniz
Beş hafta önce benim bulunduğum karar noktasındasınız. Tarayıcı otomasyon yolu bir demo için işe yarar. Yük altında üretimde arıza modu, iletilmemiş mesaj kuyruğu bulunan engellenmiş bir hesaptır.
browser-use deposu gerçekten ilgi çekici bir yazılımdır ve demolar ikna edicidir. Asıl sorun bir uyumsuzluktur: güvenilir WhatsApp otomasyonu, parmak izi kontrollerini geçen kimliği doğrulanmış bir bağlantıyı sürdürmeyi gerektirir. browser-use tarayıcı kontrolünü çözer. WhatsApp'ın yaptırım sistemi onu kimlik doğrulama katmanında kapatır.
Amacınız koddan WhatsApp mesajı göndermekse (sipariş onayları, bildirimler, chatbot yanıtları, kullanıcıların bağımlı olduğu her şey), WhatsApp oturumunu sizin adınıza yöneten bir bağlantı katmanına ihtiyacınız var. Numarayı bir kez QR tarama yoluyla bağlayın, o noktadan itibaren REST API'sini kullanın. 10 satırlık sürüm çalışır; 150 satırlık sürüm gece 2'de bozulur.
Gece saat 02:00'de ölü bir oturum kuyruğu ve sipariş güncellemelerini bekleyen 40 müşteriyle — browser-use bakımı üretimde böyle görünür. Gerçek ürün çalışması, bağlantı katmanını yönetmeyi bıraktıktan sonra başlar.
