オンボーディングメールは、製品と同じイベントデータに依存しています。Cursor から作業すれば、登録処理のハンドラーを確認し、それに対応する Brew のトリガーを作成して、メールをチェックするところまで、1か所で済ませられます。フローの公開と本番の送信の承認は、人が責任を持って行いましょう。

Brew を接続する

Cursor のMCP設定か、プロジェクトの .cursor/mcp.json に、次のサーバーを追加します。

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

Brew のOAuthでのログインを完了し、使うブランドを選択します。エージェントに get_brew_capabilities を呼び出すよう依頼しましょう。お使いのクライアントが別の設定形式を使う場合は、クライアントのセットアップガイドに従ってください。APIキーは、チャットにもリポジトリにも含めないようにしましょう。

登録とリマインダーの対象条件を分けて定義する

Cursor に、新しいアカウントをコミットするコードを探してもらいます。最初のプロジェクトの作成など、何をアクティベーションとみなすかを決めましょう。この手順では、対象条件のチェックをアプリケーション側に置き、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 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. 新しいアカウントに、ウェルカムメールが1回だけ届く。
2. アクティベーションしていないアカウントで、対象者向けのリマインダーのイベントが1つだけ発生する。
3. 予定されたチェックの前にアクティベーションしたアカウントでは、リマインダーのイベントが発生しない。
4. 再試行しても、余分な送信が発生しない。
5. フィールドが欠けていたり無効だったりすると、バックエンドが記録して処理できるエラーが発生する。

送信ドメインの用途と、同意に関する要件を確認しましょう。そのうえで、save_automation に published: true を指定して、明示的に公開します。公開したオートメーションは、実際のイベントで実行されるようになります。

シーケンス全体の設計については、ウェルカムシーケンスの記事をご覧ください。バックエンドで使うインターフェースの選び方については、MCPとREST APIの比較ガイドをご覧ください。