# Cara membuat rangkaian email onboarding dari Cursor

URL kanonis: https://brew.new/id/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Penulis: Philip Sørensen
Dipublikasikan: 2026-09-25
Diperbarui: 2026-09-29

Email onboarding bergantung pada data peristiwa yang sama dengan produk Anda. Dengan bekerja dari Cursor, Anda bisa meninjau handler pendaftaran, membuat pemicu Brew yang sesuai, dan memeriksa emailnya di satu tempat. Tetapkan satu orang yang bertanggung jawab memublikasikan alur dan menyetujui pengiriman nyata.

## Hubungkan Brew

Tambahkan server ini di pengaturan MCP Cursor atau di `.cursor/mcp.json` proyek Anda:

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

Selesaikan proses masuk OAuth Brew dan pilih merek yang dimaksud. Minta agen memanggil `get_brew_capabilities`. Ikuti [panduan penyiapan klien](https://docs.brew.new/api-reference/mcp/connect-your-client) jika klien Anda memakai format konfigurasi yang berbeda. Jangan taruh kunci API apa pun di chat maupun di repositori.

## Definisikan kelayakan pendaftaran dan pengingat secara terpisah

Minta Cursor menemukan kode yang meng-commit pembuatan akun baru. Tentukan apa yang dianggap sebagai aktivasi, seperti membuat proyek pertama. Panduan ini menempatkan pemeriksaan kelayakan di aplikasi dan memakai dua pemicu yang berbeda:

- Pemicu pendaftaran untuk email sambutan yang langsung dikirim.
- Pemicu pengingat bagi kontak yang memenuhi syarat, yang hanya dijalankan aplikasi Anda setelah memeriksa status aktivasi terkini.

Gunakan `save_trigger` untuk mendefinisikan setiap payload, termasuk string email yang wajib ada. Simpan ID pemicu yang benar-benar dikembalikan. Nama tampilan seperti `user_signed_up` tidak bisa menggantikan ID untuk API.

## Bangun dan tinjau emailnya

Contoh brief pertama yang berguna:

```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.
```

Agen bisa memakai `create_email`, `edit_email`, dan `save_automation`. Buka hasilnya di Brew dan periksa tata letak, teks, tautan, dan domain pengirimnya. Gunakan [sintaks merge tag](https://docs.brew.new/create-emails/merge-tags) yang terdokumentasi, termasuk nilai cadangan yang sudah diuji untuk nama yang kosong.

Jangan letakkan filter `activated is false` di jalur linear sebelum tindak lanjut dengan `activated is true`. Filter yang tidak lolos akan menghentikan semua langkah lanjutannya. Field peristiwa seperti `payload.activated` tetap tidak berubah setelah langkah tunggu. Sebagai alternatif dari resep yang dijadwalkan aplikasi ini, definisikan dan sinkronkan field kontak boolean, lalu periksa `contact.activated` setelah setiap langkah tunggu yang relevan. Kondisi itu membaca kontak Brew terkini, bukan database aplikasi Anda. Lihat [panduan rangkaian uji coba](/id/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Hubungkan backend

Ambil kontrak setiap pemicu dengan `get_trigger_contract`, atau buat kontraknya dengan [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Jalankan pemicu pendaftaran setelah transaksi pembuatan akun Anda di-commit.

Contoh shell ini mengasumsikan `BREW_SIGNUP_TRIGGER_ID` berisi ID yang dikembalikan saat Anda membuat pemicu, dan skemanya mendeklarasikan `firstName`:

```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"}}'
```

Gunakan kunci yang stabil untuk setiap peristiwa pendaftaran, simpan kunci itu untuk percobaan ulang, dan periksa respons yang gagal. Ikuti [kontrak idempotensi API](https://docs.brew.new/api-reference/api/idempotency).

Saat tiba waktunya mengirim pengingat, aplikasi Anda membaca data akun terkini. Jika pengguna sudah teraktivasi, sudah dihapus, atau tidak memenuhi syarat karena alasan lain, aplikasi tidak menjalankan pemicu pengingat. Jika masih memenuhi syarat, aplikasi mengirim peristiwa baru dengan data terkini. Pembaruan field kontak saja tidak membatalkan eksekusi aslinya.

## Uji sebelum memublikasikan

Gunakan `test_automation` dengan penerima yang Anda kendalikan. Periksa [perilaku pengujian saat ini](https://docs.brew.new/create-emails/build-an-automation) dan tinjau riwayat eksekusinya. Uji juga penjadwal di aplikasi Anda:

1. Akun baru menerima email sambutan satu kali.
2. Akun yang tidak aktif menghasilkan satu peristiwa pengingat yang memenuhi syarat.
3. Akun yang teraktivasi sebelum pemeriksaan terjadwal tidak menghasilkan peristiwa pengingat.
4. Percobaan ulang tidak menghasilkan pengiriman tambahan.
5. Field yang kosong atau tidak valid menghasilkan error yang dicatat dan ditangani oleh backend Anda.

Tinjau tujuan domain pengirim dan persyaratan persetujuan. Lalu publikasikan secara eksplisit dengan `save_automation` dan `published: true`. Otomatisasi yang sudah dipublikasikan bisa berjalan pada peristiwa sungguhan.

Untuk desain rangkaian yang lebih luas, lihat [rangkaian email sambutan](/id/blog/welcome-email-sequence). Untuk memilih antarmuka yang dipakai backend Anda, lihat [MCP vs REST](/id/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).