온보딩 이메일은 제품과 같은 이벤트 데이터에 의존해요. Cursor에서 작업하면 가입 핸들러를 검토하고, 그에 맞는 Brew 트리거를 만들고, 이메일을 확인하는 일을 한곳에서 할 수 있어요. 플로우 게시와 실제 발송 승인은 사람이 책임지도록 하세요.

Brew 연결하기

Cursor의 MCP 설정이나 프로젝트의 .cursor/mcp.json 파일에 이 서버를 추가하세요.

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

Brew의 OAuth 로그인을 마치고 작업할 브랜드를 선택하세요. 에이전트에게 get_brew_capabilities 도구를 호출해 달라고 요청하세요. 클라이언트가 다른 구성 형식을 쓴다면 클라이언트 설정 가이드를 따르세요. API 키는 채팅에도 저장소에도 남기지 마세요.

가입과 리마인더의 대상 조건을 따로 정하기

Cursor에게 새 계정 생성을 커밋하는 코드를 찾아 달라고 하세요. 첫 프로젝트 만들기처럼 무엇을 활성화로 볼지 정하세요. 이 안내에서는 대상 여부 확인을 애플리케이션에 두고, 서로 다른 트리거 두 개를 써요.

• 가입 직후 웰컴 이메일을 보내는 가입 트리거
• 애플리케이션이 현재 활성화 상태를 확인한 뒤에만 실행하는, 리마인더 대상임을 알리는 트리거

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 true 후속 이메일 앞의 일직선 경로에 activated is false 필터를 두지 마세요. 필터를 통과하지 못하면 그 뒤에 이어지는 단계가 모두 멈춰요. payload.activated 같은 이벤트 필드는 대기 단계가 지나도 처음 값 그대로예요. 애플리케이션이 일정을 관리하는 이 레시피 대신, 불리언 연락처 필드를 정의해 동기화하고 관련 대기 단계마다 그 뒤에서 contact.activated 값을 확인하는 방법도 있어요. 이 조건은 애플리케이션 데이터베이스가 아니라 Brew 연락처의 현재 값을 읽어요. 자세한 내용은 체험 시퀀스 가이드를 참고하세요.

백엔드 연결하기

get_trigger_contract 도구로 각 트리거의 페이로드 정의를 가져오거나, CLI로 정의를 생성하세요. 가입 트리거는 계정 트랜잭션이 커밋된 뒤에 실행하세요.

아래 셸 예시는 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"}}'

가입 이벤트마다 바뀌지 않는 키를 쓰고, 재시도할 때도 같은 키를 유지하고, 실패한 응답은 꼭 확인하세요. API 멱등성 규칙을 따르세요.

리마인더를 보낼 때가 되면 애플리케이션이 현재 계정을 읽어요. 사용자가 이미 활성화했거나, 삭제됐거나, 그 밖의 이유로 대상이 아니라면 리마인더 트리거를 실행하지 않아요. 대상이라면 현재 데이터를 담은 새 이벤트를 보내요. 연락처 필드를 업데이트하는 것만으로는 원래 실행이 취소되지 않아요.

게시하기 전에 테스트하기

직접 관리하는 수신자를 대상으로 test_automation 도구를 쓰세요. 현재 테스트 동작 방식을 확인하고 실행 기록을 살펴보세요. 애플리케이션 스케줄러도 테스트하세요.

1. 새 계정은 웰컴 이메일을 한 번만 받아요.
2. 활성화하지 않은 계정에서는 리마인더 대상 이벤트가 한 번 발생해요.
3. 예약된 확인 시점 전에 활성화한 계정에서는 리마인더 이벤트가 발생하지 않아요.
4. 재시도해도 발송이 추가로 생기지 않아요.
5. 필드가 없거나 잘못되면 오류가 나고, 백엔드가 이를 기록하고 처리해요.

발신 도메인의 용도와 수신 동의 요건을 검토하세요. 그런 다음 save_automation 도구에 published: true 값을 넣어 명시적으로 게시하세요. 게시된 자동화는 실제 이벤트에 따라 실행될 수 있어요.

시퀀스 설계 전반은 웰컴 이메일 시퀀스 글을, 백엔드가 쓸 인터페이스를 고르는 방법은 MCP와 REST 비교 글을 참고하세요.