Bir onboarding e-postası, ürününüzle aynı olay verilerine dayanır. Cursor’dan çalışmak; kayıt işleyicisini incelemenizi, ona karşılık gelen Brew tetikleyicisini oluşturmanızı ve e-postayı kontrol etmenizi tek bir yerde mümkün kılar. Akışı yayımlama ve canlı gönderimleri onaylama sorumluluğunu yine bir kişide tutun.

Brew bağlantısını kurun

Bu sunucuyu Cursor’ın MCP ayarlarına ya da projenizdeki .cursor/mcp.json dosyasına ekleyin:

{
  "mcpServers": {
    "brew": { "url": "https://brew.new/api/mcp" }
  }
}

Brew için OAuth girişini tamamlayın ve çalışmak istediğiniz markayı seçin. Ajandan get_brew_capabilities aracını çağırmasını isteyin. İstemciniz farklı bir yapılandırma biçimi kullanıyorsa istemci kurulum rehberini izleyin. API anahtarlarını sohbete ve kod deposuna koymayın.

Kayıt ve hatırlatma uygunluğunu ayrı ayrı tanımlayın

Cursor’dan yeni bir hesabı veritabanına kaydeden kodu bulmasını isteyin. İlk projeyi oluşturmak gibi, neyin aktivasyon sayılacağına karar verin. Bu adım adım anlatım, uygunluk kontrollerini uygulamada tutar ve iki ayrı tetikleyici kullanır:

• Hemen gönderilecek hoş geldin e-postası için bir kayıt tetikleyicisi.
• Uygulamanızın yalnızca güncel aktivasyon durumunu kontrol ettikten sonra tetiklediği, uygun kişiler için bir hatırlatma tetikleyicisi.

Her payload yapısını, metin türündeki zorunlu e-posta alanı dâhil, save_trigger ile tanımlayın. Dönen gerçek tetikleyici kimliklerini kaydedin. user_signed_up gibi bir görünen ad, API tanımlayıcısının yerine geçmez.

E-postaları oluşturun ve inceleyin

İşe yarar bir ilk brief şöyle olabilir:

Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.

Ajan create_email, edit_email ve save_automation araçlarını kullanabilir. Sonuçları Brew içinde açın; düzeni, metni, bağlantıları ve gönderim alan adını inceleyin. Dokümantasyondaki birleştirme etiketi söz dizimini kullanın; eksik bir ad için test edilmiş bir varsayılan değer de ekleyin.

Doğrusal bir yolda, activated is true koşuluna bağlı bir takip e-postasının önüne activated is false filtresi koymayın. Koşulu sağlanmayan bir filtre, kendisinden sonra gelen tüm adımları durdurur. payload.activated gibi olay alanları bir beklemeden sonra da sabit kalır. Uygulamanın zamanladığı bu tarife alternatif olarak, evet/hayır türünde bir kişi alanı tanımlayıp senkronize edin ve ilgili her beklemeden sonra contact.activated alanını kontrol edin. Bu koşul, uygulamanızın veritabanını değil, Brew içindeki güncel kişi kaydını okur. Ayrıntılar için deneme süresi serisi rehberine göz atın.

Sunucu tarafını bağlayın

Her tetikleyicinin sözleşmesini get_trigger_contract ile alın ya da sözleşmeleri CLI ile üretin. Kayıt tetikleyicisini, hesap oluşturma işlemi (transaction) veritabanına işlendikten sonra tetikleyin.

Aşağıdaki kabuk örneği, BREW_SIGNUP_TRIGGER_ID değişkeninin tetikleyiciyi oluşturduğunuzda dönen tanımlayıcıyı içerdiğini ve tetikleyici şemasında firstName alanının tanımlı olduğunu varsayar:

curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-example-account-123" \
  -d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'

Her kayıt olayı için sabit bir anahtar kullanın, yeniden denemelerde aynı anahtarı koruyun ve başarısız yanıtları inceleyin. API idempotency sözleşmesine uyun.

Bir hatırlatmanın zamanı geldiğinde uygulamanız hesabın güncel hâlini okur. Kullanıcı aktive olmuşsa, silinmişse ya da başka bir nedenle uygun değilse hatırlatma tetikleyicisini tetiklemez. Aksi hâlde güncel verilerle yeni bir olay gönderir. Bir kişi alanının güncellenmesi tek başına ilk çalıştırmayı iptal etmez.

Yayımlamadan önce test edin

test_automation aracını kontrolünüzdeki alıcılarla kullanın. Güncel test davranışını kontrol edin ve çalıştırma geçmişini inceleyin. Uygulamadaki zamanlayıcıyı da test edin:

1. Yeni bir hesap hoş geldin e-postasını bir kez alır.
2. Aktive olmamış bir hesap, uygun kişiler için tek bir hatırlatma olayı üretir.
3. Planlanan kontrolden önce aktive olan bir hesap hiçbir hatırlatma olayı üretmez.
4. Bir yeniden deneme fazladan bir gönderim oluşturmaz.
5. Eksik ya da geçersiz alanlar, sunucunuzun kaydettiği ve ele aldığı bir hata üretir.

Gönderim alan adının amacını ve izin gereksinimlerini gözden geçirin. Ardından otomasyonu save_automation ve published: true ile açıkça yayımlayın. Yayımlanmış bir otomasyon gerçek olaylarla çalışabilir.

Serinin genel kurgusu için hoş geldin e-posta serileri yazımıza, sunucunuzun kullanacağı arayüzü seçmek için de MCP ve REST API karşılaştırmamıza göz atın.