# Cursor’dan e-posta onboarding serisi nasıl oluşturulur?

Kanonik URL: https://brew.new/tr/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Yazar: Philip Sørensen
Yayımlandı: 2026-09-25
Güncellendi: 2026-09-29

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:

```json
{
  "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](https://docs.brew.new/api-reference/mcp/connect-your-client) 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:

```text
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](https://docs.brew.new/create-emails/merge-tags) 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](/tr/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) 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](https://docs.brew.new/api-reference/guides/typed-payload-contracts) 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:

```bash
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](https://docs.brew.new/api-reference/api/idempotency) 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ı](https://docs.brew.new/create-emails/build-an-automation) 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](/tr/blog/welcome-email-sequence) yazımıza, sunucunuzun kullanacağı arayüzü seçmek için de [MCP ve REST API](/tr/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) karşılaştırmamıza göz atın.