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:

{
  "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 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:

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

Hubungkan backend

Ambil kontrak setiap pemicu dengan get_trigger_contract, atau buat kontraknya dengan CLI. 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:

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.

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 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. Untuk memilih antarmuka yang dipakai backend Anda, lihat MCP vs REST.