อีเมลแนะนำการใช้งานพึ่งพาข้อมูลเหตุการณ์ชุดเดียวกับผลิตภัณฑ์ของคุณ การทำงานจาก Cursor ช่วยให้คุณตรวจโค้ดส่วนที่จัดการการสมัครใช้งาน สร้างทริกเกอร์ใน Brew ที่ตรงกัน และตรวจอีเมลได้ในที่เดียว ทั้งนี้ควรให้มีคนรับผิดชอบการเผยแพร่โฟลว์และการอนุมัติการส่งจริง

เชื่อมต่อ Brew

เพิ่มเซิร์ฟเวอร์นี้ในการตั้งค่า MCP ของ Cursor หรือในไฟล์ .cursor/mcp.json ของโปรเจกต์:

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

เข้าสู่ระบบผ่าน OAuth ของ Brew ให้เสร็จ แล้วเลือกแบรนด์ที่ต้องการ ขอให้เอเจนต์เรียก get_brew_capabilities หากไคลเอนต์ของคุณใช้รูปแบบการกำหนดค่าอื่น ให้ทำตามคู่มือการตั้งค่าไคลเอนต์ และอย่าใส่คีย์ API ใด ๆ ไว้ในแชทหรือในรีโพสิทอรี

กำหนดเกณฑ์ของการสมัครและอีเมลเตือนแยกจากกัน

ขอให้ Cursor หาโค้ดที่บันทึกบัญชีใหม่จนเสร็จสมบูรณ์ (commit) แล้วตัดสินใจว่าอะไรนับเป็นการเริ่มใช้งานจริง เช่น การสร้างโปรเจกต์แรก คู่มือนี้ตรวจการเข้าเกณฑ์ไว้ในแอปพลิเคชัน และใช้ทริกเกอร์ 2 ตัวที่แยกจากกัน:

• ทริกเกอร์การสมัครใช้งาน สำหรับอีเมลต้อนรับที่ส่งทันที
• ทริกเกอร์อีเมลเตือนสำหรับผู้ที่เข้าเกณฑ์ ซึ่งแอปพลิเคชันของคุณจะเรียกก็ต่อเมื่อตรวจสถานะการเริ่มใช้งานจริงปัจจุบันแล้วเท่านั้น

ใช้ save_trigger กำหนดเพย์โหลดของแต่ละทริกเกอร์ รวมถึงสตริงอีเมลที่จำเป็นต้องมี แล้วบันทึก ID ทริกเกอร์จริงที่ได้กลับมา ชื่อที่ใช้แสดงอย่าง user_signed_up ใช้แทนตัวระบุของ API ไม่ได้

สร้างและตรวจทานอีเมล

บรีฟแรกที่มีประโยชน์คือ:

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.

เอเจนต์ใช้ create_email, edit_email และ save_automation ได้ เปิดผลลัพธ์ใน Brew แล้วตรวจเลย์เอาต์ ข้อความ ลิงก์ และโดเมนผู้ส่ง ใช้ไวยากรณ์แท็กตัวแปรตามที่ระบุไว้ในเอกสาร รวมถึงค่าสำรองที่ทดสอบแล้วสำหรับกรณีที่ไม่มีชื่อ

อย่าวางตัวกรอง activated is false ไว้ในเส้นทางเดียวกันแบบเส้นตรงก่อนอีเมลติดตามผลที่ใช้ activated is true เพราะเมื่อตัวกรองไม่ผ่าน ขั้นตอนทั้งหมดที่ตามมาจะหยุดไปด้วย ฟิลด์ของเหตุการณ์อย่าง payload.activated จะคงค่าเดิมหลังขั้นตอนรอ ทางเลือกอื่นนอกเหนือจากสูตรที่ให้แอปพลิเคชันจัดตารางเวลานี้ คือกำหนดและซิงค์ฟิลด์ผู้ติดต่อประเภทใช่/ไม่ใช่ (boolean) แล้วตรวจ contact.activated หลังขั้นตอนรอแต่ละขั้นที่เกี่ยวข้อง เงื่อนไขนั้นจะอ่านข้อมูลผู้ติดต่อปัจจุบันใน Brew ไม่ใช่ฐานข้อมูลของแอปพลิเคชันคุณ ดูคู่มือลำดับอีเมลช่วงทดลองใช้

เชื่อมต่อแบ็กเอนด์

ดึงสคีมาเพย์โหลดของแต่ละทริกเกอร์ด้วย get_trigger_contract หรือสร้างสคีมาด้วย CLI แล้วเรียกทริกเกอร์การสมัครใช้งานหลังจากทรานแซกชันการสร้างบัญชี commit สำเร็จแล้ว

ตัวอย่างคำสั่ง shell นี้สมมติว่า BREW_SIGNUP_TRIGGER_ID เก็บตัวระบุที่ได้กลับมาตอนสร้างทริกเกอร์ และสคีมาของทริกเกอร์ประกาศ 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"}}'

ใช้คีย์ที่คงที่ 1 คีย์ต่อเหตุการณ์การสมัครแต่ละครั้ง เก็บคีย์ไว้ใช้ตอนลองใหม่ และตรวจดูการตอบกลับที่ล้มเหลว ทำตามข้อกำหนด idempotency ของ API

เมื่อถึงเวลาส่งอีเมลเตือน แอปพลิเคชันของคุณจะอ่านข้อมูลบัญชีปัจจุบัน หากผู้ใช้เริ่มใช้งานจริงแล้ว ถูกลบไปแล้ว หรือไม่เข้าเกณฑ์ด้วยเหตุผลอื่น แอปพลิเคชันจะไม่เรียกทริกเกอร์อีเมลเตือน มิฉะนั้นจะส่งเหตุการณ์ใหม่พร้อมข้อมูลปัจจุบัน การอัปเดตฟิลด์ผู้ติดต่ออย่างเดียวไม่ได้ยกเลิกรอบการทำงานเดิม

ทดสอบก่อนเผยแพร่

ใช้ test_automation กับผู้รับที่ควบคุมได้ ตรวจดูการทำงานของการทดสอบในปัจจุบัน และตรวจประวัติการทำงาน ทดสอบตัวจัดตารางเวลาของแอปพลิเคชันด้วย:

1. บัญชีใหม่ได้รับอีเมลต้อนรับเพียงครั้งเดียว
2. บัญชีที่ยังไม่เริ่มใช้งานจริงทำให้เกิดเหตุการณ์เตือนสำหรับผู้ที่เข้าเกณฑ์ 1 รายการ
3. บัญชีที่เริ่มใช้งานจริงก่อนถึงเวลาตรวจตามกำหนดจะไม่ทำให้เกิดเหตุการณ์เตือน
4. การลองใหม่ไม่ทำให้เกิดการส่งเกินมา
5. ฟิลด์ที่ขาดหายหรือไม่ถูกต้องทำให้เกิดข้อผิดพลาดที่แบ็กเอนด์ของคุณบันทึกและจัดการได้

ตรวจวัตถุประสงค์ของโดเมนผู้ส่งและข้อกำหนดด้านความยินยอม จากนั้นเผยแพร่อย่างชัดเจนด้วย save_automation และ published: true เมื่อเผยแพร่แล้ว ระบบอัตโนมัติจะทำงานกับเหตุการณ์จริงได้

หากต้องการดูการออกแบบลำดับอีเมลในภาพกว้าง ดูลำดับอีเมลต้อนรับ และหากต้องการเลือกอินเทอร์เฟซที่แบ็กเอนด์ของคุณจะใช้ ดู MCP กับ REST