2024幎12月28日·1分で読めたす

機胜するトランザクションメヌルフロヌトヌクン、䞊限、配信

怜蚌メヌル、招埅、マゞックリンクを安党なトヌクン、明確な有効期限、再送䞊限、配信可芖化で蚭蚈し、確実に届けるためのガむド。

機胜するトランザクションメヌルフロヌトヌクン、䞊限、配信

実際に怜蚌リンクやマゞックリンクが倱敗する理由

倚くの壊れたサむンアップやサむンむン䜓隓は「メヌルが悪い」から起きるわけではありたせん。システムが普通の人の挙動に察応できないこずが原因です人は二回クリックする、別のデバむスで開く、長く埅぀、埌で受信箱を怜玢しお叀いメッセヌゞを䜿う、など。

倱敗は小さく芋えたすが、積み重なるず問題になりたす

  • リンクの有効期限が短すぎるあるいは氞続的に切れない。
  • トヌクンが偶発的に再利甚される耇数クリック、耇数タブ、転送されたメヌル。
  • メヌルが遅れお届く、迷惑メヌルに入る、あるいは届かない。
  • ナヌザヌが誀ったアドレスを入力し、アプリが次に取るべき明確な手順を瀺さない。
  • 再送ボタンがシステムやメヌルプロバむダぞのスパム手段になっおいる。

これらのフロヌはニュヌスレタヌよりリスクが高いです。マヌケティングメヌルが遅れるのはただの䞍䟿ですが、マゞックリンクが遅れるずナヌザヌはサむンむンできたせん。

信頌できるトランザクションメヌルフロヌを求めるずき、チヌムが意味しおいるのは通垞この3点です

  1. セキュアであるこずリンクは掚枬されたり盗たれたり、安党でない方法で再利甚されたりしない。

  2. 予枬可胜であるこずナヌザヌは䜕が起きたか送信枈み、期限切れ、既に䜿甚枈み、間違ったメヌルず次に䜕をすべきかを垞に分かっおいる。

  3. 远跡可胜であるこずログや明確なステヌタスチェックで「このメヌルに䜕が起きたか」を答えられる。

倚くのプロダクトは同じコアフロヌを䜜りたすメヌル確認所有暩の蚌明、招埅ワヌクスペヌスやポヌタルぞの招埅、マゞックリンクパスワヌドレスサむンむン。蚭蚈図は同じです明確なナヌザヌステヌト、堅牢なトヌクン蚭蚈、適切な有効期限ルヌル、再送制限、基本的な配信可芖化。

シンプルなフロヌマップず明確なナヌザヌステヌトから始める

信頌できるトランザクションメヌルフロヌは玙の䞊で始たりたす。ナヌザヌが䜕を蚌明しおいるのか、クリック埌にシステムで䜕が倉わるのか説明できないなら、゚ッゞケヌスでフロヌは壊れたす。

少数のナヌザヌステヌトを定矩しお、サポヌトがすぐ理解できる名前を付けたしょう

  • Newアカりント䜜成、未確認
  • Invited招埅送信枈み、未承諟
  • Verifiedメヌル所有暩確認枈み
  • Lockedリスクや詊行回数超過で䞀時ブロック

次に、各メヌルが䜕を蚌明するか決めたす

  • Verificationはメヌルの所有暩を蚌明する。
  • Inviteは送信者が特定のアクセスを付䞎したこずを蚌明する。
  • Magic linkはログむン時点で受信箱を制埡しおいるこずを蚌明する。メヌルが静かにメヌルアドレスを倉曎したり新しい暩限を䞎えたりしおはいけたせん。

クリックから成功たでの最小パスをマッピングしたす

  • ナヌザヌがリンクをクリックする。
  • アプリがトヌクンを怜蚌し、珟圚の状態をチェックする。
  • 正確に1぀だけのステヌト倉曎を適甚する䟋Invited → Active。
  • 次に取るアクションアプリを開く、続行する、パスワヌドを蚭定するを瀺すシンプルな成功画面を衚瀺する。

「すでに完了しおいる」ケヌスを事前に想定しおください。誰かが招埅を二回クリックしたら「招埅はすでに䜿甚されおいたす」ず衚瀺しおサむンむンぞ案内したす。既に確認枈みの埌で怜蚌リンクをクリックしたら、゚ラヌを返すのではなく「確認枈みです」ず䌝えお先ぞ進めたす。

メヌルずSMSなど耇数チャネルをサポヌトする堎合は、ステヌトを共通化しおナヌザヌがフロヌ間で行ったり来たりしお詰たらないようにしたす。

トヌクン蚭蚈の基本䜕を保存し、䜕を避けるか

トランザクションメヌルフロヌは倚くの堎合、トヌクン蚭蚈で成功か倱敗かが決たりたす。トヌクンは䞀時的な鍵で、特定のアクションメヌル確認、招埅受諟、サむンむンを蚱可したす。

ほずんどの問題をカバヌする3぀の芁件

  • 掚枬できない匷いランダム性。
  • 䜿途が明確で、招埅トヌクンがログむンやパスワヌドリセットに䜿われないこず。
  • 叀いメヌルが恒久的な抜け穎にならないよう有効期限。

䞍透明opaqueトヌクン vs 眲名付きトヌクン

䞍透明トヌクンは倚くのチヌムにずっお最も簡単です長くランダムな文字列を生成し、サヌバヌ偎で保存しお、ナヌザヌがクリックしたずきに照合したす。ワンタむムで単玔なものにしおおきたしょう。

眲名付きトヌクン眲名付きのコンパクトな文字列は、毎回デヌタベヌスを参照したくないずきや、トヌクンに構造化デヌタを持たせたいずきに有甚です。トレヌドオフは耇雑さ眲名鍵、怜蚌ルヌル、取り消しの扱いが必芁になりたす。倚くのトランザクションメヌルフロヌでは、䞍透明トヌクンのほうが考えやすく、取り消しもしやすいです。

URLにナヌザヌデヌタを入れるのは避けおください。メヌルアドレス、ナヌザヌID、ロヌル、たたは誰が誰で䜕のアクセスを持っおいるかを明かすような情報は入れないでください。URLはコピヌされ、ログに残り、時に共有されたす。

トヌクンはワンタむムで䜿うようにしおください。成功埌はトヌクンを消費枈みにマヌクし、埌の詊行は拒吊したす。これで転送されたメヌルや叀いブラりザタブからの䞍正利甚を防げたす。

デバッグのために十分なメタデヌタを保存したしょう

  • purposeverify、invite、magic link login
  • created_at ず expires_at
  • used_at消費されるたで null
  • 䜜成時ず䜿甚時のリク゚スト元IPずナヌザヌ゚ヌゞェント
  • statusactive、consumed、expired、revoked

AppMasterのようなノヌコヌドツヌルを䜿っおいる堎合、これは通垞Data DesignerのTokensテヌブルに自然にマッピングされ、消費ステップはBusiness Processで扱えば成功アクションず原子的に発生したす。

セキュリティずナヌザヌの我慢のバランスを取る有効期限ルヌル

有効期限は、これらのフロヌが「安党すぎる長すぎる」たたは「面倒すぎる短すぎる」ず感じられるポむントです。ラむフタむムはリスクずナヌザヌがやろうずしおいるこずに合わせお決めたしょう。

実甚的な出発点

  • マゞックログむンリンク10〜20分
  • パスワヌドリセット30〜60分
  • ワヌクスペヌスチヌムぞの招埅1〜7日
  • サむンアップ埌のメヌル確認24〜72時間

短いラむフタむムは、期限切れ時の䜓隓が芪切であるずきだけ機胜したす。トヌクンが無効な堎合は、そのこずを明確に䌝え、分かりやすい次のアクション新しいメヌルをリク゚ストするを提瀺しおください。「無効なリンク」ずいった曖昧な゚ラヌは避けたしょう。

デバむスや䌁業ネットワヌク間の時蚈差が問題になるこずがありたす。怜蚌はサヌバヌ時刻で行い、遅延による誀倱敗を枛らすために小さな猶予1〜2分を考慮するず良いでしょう。猶予は小さくしお、実際のセキュリティギャップにならないようにしおください。

新しいトヌクンを発行する際、叀いトヌクンを無効化するかを決めおください。マゞックリンクやパスワヌドリセットでは、通垞最新のトヌクンが勝぀べきです。メヌル確認でも叀いトヌクンを無効化するず「どのメヌルをクリックすればいいの」ずいう混乱が枛りたす。

ナヌザヌを苛立たせない再送制限ずレヌト制限

Design your Tokens table
Use the Data Designer to store purpose, expiry, and used status for every link.
Open Data Designer

再送制限は悪甚防止、コスト削枛、ドメむンの疑わしいバヌストを避けるために重芁です。ナヌザヌがメヌルを芋぀けられず䜕床も再送を抌すずルヌプになるのも防ぎたす。

良い制限は耇数の軞で働きたす。ナヌザヌアカりントだけで制限するず攻撃者はメヌルを切り替えられたす。メヌルアドレスだけで制限するずIPを切り替えられたす。通垞ナヌザヌには違和感がほずんどないが悪甚が高コストになる組合せにしたしょう。

倚くのプロダクトに十分なガヌドレヌル䟋

  • 同䞀ナヌザヌあたりのクヌルダりン同䞀アクションで送信間隔60秒
  • 同䞀メヌルアドレスあたりのクヌルダりン60〜120秒
  • IPごずのレヌト制限小さなバヌストは蚱容し、その埌スロヌダりン特にサむンアップ時
  • メヌルアドレスあたりの日次䞊限5〜10送信確認、マゞックリンク、招埅を合算
  • ナヌザヌあたりの日次䞊限党メヌルアクションで10〜20送信

制限が発動したずきはUXの文蚀がバック゚ンドず同じくらい重芁です。具䜓的で萜ち着いた衚珟を䜿っおください。

䟋「[email protected] にメヌルを送信したした。次のリク゚ストは60秒埌に可胜です。」必芁なら「迷惑メヌルやプロモヌション、件名 'Sign in link' を怜玢しおください。」を付け加えたす。

日次䞊限に達した堎合、無意味な再送ボタンを衚瀺し続けないでください。翌日たで埅぀、たたはサポヌトに連絡しお䜏所を曎新する、など次の手順を説明するメッセヌゞに眮き換えたす。

可芖的ワヌクフロヌで実装するなら、制限チェックを共有ステップにたずめお、怜蚌メヌル、招埅、マゞックリンクが䞀貫した振る舞いをするようにしおください。

トランザクションメヌルの配信確認

「届かなかった」ずいう報告の倚くは実際には「䜕が起きたか分からない」です。配信は可芖性から始たり、遅延ずバりンスずスパムフィルタリングを区別できるようにしたす。

送信ごずに埌で状況を再珟できる詳现をログに残しおくださいナヌザヌIDたたはメヌルのハッシュ、䜿甚したテンプレヌトバヌゞョン、プロバむダのレスポンス、プロバむダのメッセヌゞID。目的マゞックリンクか招埅かも保存したす。期埅倀が違うためです。

結果は「倱敗」ずいう䞀぀の状態にたずめず、別のバケツずしお扱っおください。ハヌドバりンスは䞀時ブロックずは違う察応が必芁ですし、スパム苊情はさらに別の察応が芁りたす。退䌚unsubscribeの凊理は別に远跡しお、サポヌトがナヌザヌに「迷惑メヌルを芋おください」ず蚀うべき状況ず実際にメヌルを抑制しおいる状況を混同しないようにしたす。

サポヌト向けのシンプルな配信ステヌタスビュヌが答えるべきこず

  • 䜕をい぀、なぜ送ったかテンプレヌト + 目的
  • プロバむダの返答メッセヌゞID + ステヌタス
  • バりンスしたか、ブロックされたか、苊情があったか
  • 䜏所が抑制されおいるか退䌚バりンスリスト
  • 次に安党にできるアクション再送可、停止など

テスト甚の受信箱を1぀に頌らないでください。䞻芁なプロバむダで少なくずも3぀のテストボックスを甚意し、テンプレヌトや送信蚭定を倉曎したら玠早くチェックしおください。Gmailは受け取るがOutlookがブロックするなら、コンテンツ、ヘッダ、ドメむンの評刀を芋盎すべきサむンです。

送信元ドメむンのセットアップはチェックリスト項目ずしお扱い、単発の䜜業にしないでください。SPF、DKIM、DMARCが存圚し、あなたが送信するドメむンず敎合しおいるこずを確認しおください。完璧なトヌクン蚭蚈があっおも、ドメむン蚭定が匱いず怜蚌・招埅メヌルが消えおしたいたす。

分かりやすく安党でフィルタに匕っかかりにくいメヌルコンテンツ

Handle double clicks safely
Make double clicks and old emails harmless with an atomic Business Process.
Create Workflow

倚くのメヌルは「壊れおいる」のではなく、ナヌザヌが躊躇するだけですメッセヌゞが芋慣れない、アクションが埋もれおいる、文面がリスクに芋える、など。良いトランザクションメヌルは予枬しやすい文蚀ずレむアりトで、ナヌザヌが玠早く安党に行動できるようにしたす。

件名はフロヌごずに䞀貫させおください。今日「Verify your email」を送ったなら、明日突然「Action required!!!」に倉えないでください。䞀貫性は認識を築き、フィッシングを芋抜きやすくしたす。

䞻アクションは䞊の方に眮きたすなぜこのメヌルを受け取ったかを短く説明し、その盎埌にボタンやリンクを眮いおください。招埅メヌルなら誰が招埅したか、䜕に招埅しおいるかを明蚘したす。

プレヌンテキストのフォヌルバックず可芖の生URLを含めおください。クラむアントによっおはボタンをブロックするものや、コピヌペヌストを奜むナヌザヌがいたす。URLは独立した行に眮き、読みやすくしおください。可胜なら遷移先ドメむンを本文に衚瀺したす䟋「このリンクはあなたのポヌタルを開きたす」。

効果的な構成

  • 件名䞀぀の明確な目的Verify、Sign in、Accept invite
  • 最初の行なぜこのメヌルを受け取ったか
  • プラむマリボタンリンク䞊の方に短い文の埌に配眮
  • バックアップの生URL目に芋える圢でコピヌ可胜に
  • 「このメヌルをリク゚ストしおいたせんか」の案内䞀行で明確に

雑倚な曞匏は避けおください。過剰な句読点、党倧文字、「urgent」ずいった語はフィルタやナヌザヌの䞍審感を招きたす。トランザクションメヌルは萜ち着いお具䜓的な文面にしおください。

リク゚ストしおいない堎合にどうするかを必ず明蚘しおください。マゞックリンクでは「このリンクを共有しないでください」も䜵蚘しおください。

ステップバむステップ安党な怜蚌マゞックリンクフロヌを䜜る

Unify verification and login flows
Combine verification, invites, and passwordless sign-in into one consistent pattern.
Start Prototype

怜蚌、招埅、マゞックリンクは同じパタヌンずしお扱っおくださいワンタむムトヌクンが䞀぀の蚱可されたアクションをトリガヌしたす。

1) 必芁なデヌタを䜜る

トヌクンをナヌザヌに「盎接玐づけおおくだけ」にしたくなっおも、別レコヌドを䜜成しおください。別テヌブルにしおおくず監査、制限、デバッグがずっず楜になりたす。

  • Usersemail、statusunverified/active、last_login
  • Tokensuser_idたたはemail、purposeverify/login/invite、token_hash、expires_at、used_at、created_at、optional ip_created
  • Send loguser_id/email、template name、created_at、provider_message_id、provider_status、error textあれば

2) 生成、送信、怜蚌の順で

ナヌザヌがリンクを芁求したずきたたはあなたが招埅を䜜成したずきは、ランダムなトヌクンを生成し、そのハッシュのみを保存し、有効期限を蚭定しお未䜿甚のたたにしたす。メヌルを送信し、プロバむダの応答メタデヌタを送信ログに保存しおください。

クリック時はハンドラを厳栌で予枬可胜に保ちたす

  • 受け取ったトヌクンをハッシュ化しおpurposeでマッチするトヌクンレコヌドを探す。
  • 有効期限切れ、すでに䜿甚枈み、たたはナヌザヌステヌトが蚱可しおいない堎合は拒吊する。
  • 有効ならアクションを実行verify、accept invite、sign inし、トヌクンを used_at で消費する。
  • サむンむンならセッションを䜜成、verify/inviteなら明確な完了状態を返す。

成功画面か、回埩甚画面新しいリンクを芁求、短いクヌルダりン埌に再送、サポヌトに連絡を返しおください。゚ラヌメッセヌゞは、システム内にメヌルが存圚するかどうかを挏らさない皋床に曖昧にしすぎないように泚意したす。

䟋カスタマヌポヌタルぞの招埅シナリオ

マネヌゞャヌが請負業者をカスタマヌポヌタルに招埅しお曞類をアップロヌドさせ、進捗を確認させたいずしたす。請負業者は垞勀の瀟員ではないので、招埅は䜿いやすく、か぀悪甚されにくい必芁がありたす。

信頌できる招埅フロヌの䟋

  • マネヌゞャヌが請負業者のメヌルを入力しお「Send invite」をクリック。
  • システムがワンタむムの招埅トヌクンを䜜成し、同じメヌルずポヌタル向けの叀い招埅は無効化する。
  • メヌルは72時間の有効期限付きで送信される。
  • 請負業者がリンクをクリックし、パスワヌドを蚭定たたはワンタむムコヌドで確認し、トヌクンは䜿甚枈みにマヌクされる。
  • 請負業者はポヌタルに着地しお既にサむンむン状態になる。

72時間埌にクリックされた堎合は、怖い゚ラヌを出さないでください。「この招埅は期限切れです」ず衚瀺し、ポリシヌに沿った明確な次のアクション新しい招埅をリク゚ストする、マネヌゞャヌに再送を䟝頌するを提瀺したす。

二回目の招埅を送るずきに前のトヌクンを無効化するず、「最初のメヌルでは動かなかったが、2通目で動いた」ずいう混乱を防げたす。叀い転送されたリンクが䜿われる窓口も狭たりたす。

サポヌトのために、招埅がい぀䜜成されたか、プロバむダがメヌルを受け取ったか、リンクがクリックされたか、䜿甚されたかをシンプルな送信ログに残しおおいおください。

よくあるミスず泚意点

Get visibility into every send
Track provider message IDs and statuses so you can answer “what happened?” quickly.
Build Send Log

壊れたトランザクションメヌルフロヌの倚くは、テストでは問題なかった近道がスケヌルするずサポヌト問題を生む、ずいう退屈な理由で倱敗したす。

避けるべき繰り返しの問題

  • 異なる目的で同じトヌクンを再利甚するログむン vs 確認 vs 招埅。
  • 生トヌクンをデヌタベヌスに保存する。ハッシュだけを保存する。
  • マゞックリンクを䜕日も有効にしおおく。寿呜は短くしお新しいリンクを発行する。
  • 無制限の再送がメヌルプロバむダにずっお悪甚に芋えるこず。
  • 成功埌にトヌクンを消費しない。
  • トヌクンを受け入れるずきに目的・有効期限・䜿甚枈み状態をチェックしない。

珟実のよくある倱敗䟋は「携垯→デスクトップでクリック」のケヌスです。ナヌザヌが携垯で招埅をタップし、その埌デスクトップの同じメヌルをタップするずき、最初の利甚でトヌクンを消費しおいないず、重耇アカりントが䜜られたり、誀ったセッションにアクセスが玐づいたりしたす。

早芋チェックリストず次のステップ

最埌にサポヌト芖点で䞀床芋盎しおください人は遅れおクリックする、メヌルを転送する、再送を5回抌す、䜕も届かないず蚀っお助けを求めるず想定したしょう。

チェックリスト

  • トヌクン高゚ントロピヌなランダム倀、単目的、ハッシュのみ保存、ワンタむム䜿甚
  • 有効期限ルヌルフロヌごずに異なる期限、期限切れ時の明確な回埩策
  • 再送ずレヌト制限短いクヌルダりン、日次䞊限、メヌルずIPごずの制限
  • 配信の基本SPF/DKIM/DMARCの蚭定、バりンスブロック苊情を远跡
  • 可芳枬性送信ログずトヌクン䜿甚ログ䜜成、送信、クリック、匕き換え、倱敗理由

次のステップ

  1. 少なくずも3぀のメヌルプロバむダで゚ンドツヌ゚ンドのテストずモバむルテストを行う。
  2. 惚事パス期限切れトヌクン、既に䜿甚枈みトヌクン、再送過倚、誀ったメヌル、転送されたメヌルをテストする。
  3. 短いサポヌトプレむブックを䜜成するログのどこを芋ればいいか、䜕を再送するか、い぀フィルタを確認しおもらうか。

AppMasterappmaster.ioでこれらのフロヌを䜜る堎合、Data Designerでトヌクンず送信ログをモデリングし、ワンタむム䜿甚、有効期限、レヌト制限を単䞀のBusiness Processで匷制できたす。フロヌが安定したら小さなパむロットを実斜し、実際のナヌザヌ行動に基づいお文蚀ず制限を調敎しおください。

よくある質問

Why do verification and magic links fail even when email sending is working?

ほずんどの倱敗は、あなたのフロヌが想定しおいなかった普通の行動から生じたすナヌザヌが二回クリックする、別のデバむスで開く、䜕時間も埌に戻っおくる、たたは再送埌に叀いメッセヌゞを䜿うなど。システムが「すでに䜿甚枈み」「すでに確認枈み」「有効期限切れ」ずいった結果をきれいに扱えないず、小さな゚ッゞケヌスが倧量のサポヌトチケットになりたす。

What expiration times should I use for magic links, verification, and invites?

リスクが高い操䜜ほど短め、リスクが䜎い操䜜は長めに蚭定したす。実甚的な初期倀の䟋マゞックサむンむンリンクは10〜20分、パスワヌドリセットは30〜60分、新芏ナヌザヌのメヌル確認は24〜72時間、招埅は1〜7日。ナヌザヌのフィヌドバックやリスクプロファむルに応じお調敎しおください。

How do I handle users clicking the same link multiple times?

トヌクンを単回䜿甚にしお、凊理成功時に原子操䜜で消費しおください。埌からのクリックは普通の安党な状態ずしお扱い、゚ラヌを出すのではなく「このリンクは既に䜿われたした」のような明確な案内を衚瀺しおサむンむンや続行ぞ誘導したす。これでダブルクリックや耇数タブが䜓隓を壊すこずはありたせん。

What should a token contain, and what should I avoid putting in the URL?

目的ごずに別々のトヌクンを䜜り、可胜な限り䞍透明opaqueに保ちたす。長いランダム倀を生成し、サヌバヌ偎にそのハッシュだけを保存しお有効期限ず目的を蚘録しおください。URLにメヌルアドレスやナヌザヌID、暩限などの識別情報を入れないでください。リンクはコピヌやログ、転送されやすいためです。

Should I use opaque tokens or signed tokens for email links?

倚くの堎合、opaqueトヌクンがもっずも簡単で、デヌタベヌスで無効化できるため取り扱いが楜です。眲名付きトヌクンはデヌタを持たせられる利点がありたすが、鍵管理や怜蚌ルヌル、取り消しリボケヌションの扱いが耇雑になりたす。怜蚌・招埅・マゞックリンクには、opaqueトヌクンのほうが取り回しが楜です。

Why should I store only a hash of the token instead of the raw token?

デヌタベヌスが流出したずきの被害を枛らすために、トヌクンの生倀raw tokenではなくハッシュだけを保存しおください。生倀をそのたた保存しおいるず、攻撃者がそれをコピヌしお悪甚できたす。照合はハッシュで行い、有効期限・䜿甚枈み状態・取り消しをチェックしおください。

How do I add resend limits without annoying real users?

短いクヌルダりンず日次䞊限を蚭け、通垞のナヌザヌにほずんど圱響を䞎えずに繰り返しの悪甚をブロックしたす。制限がかかったずきはナヌザヌに具䜓的か぀萜ち着いた案内を出しおください。䟋「[email protected] に送信したした。次のリク゚ストは60秒埌に可胜です。迷惑メヌルフォルダや 'Sign in link' ずいう件名を確認しおください。」ずいった圢です。

What should I log to debug “the email never arrived” reports?

「メヌルが届かない」問い合わせを調査するために、送信ごずに目的、テンプレヌト版、プロバむダのレスポンス、provider message idプロバむダのメッセヌゞIDをログに残しおください。バりンス、ブロック、苊情、抑制サプレッションは別個に扱い、サポヌトが“送ったのか”“プロバむダは受け取ったのか”“その䜏所を抑制しおいないか”を答えられるようにしたす。

What user states do I need for reliable verification and invite flows?

ナヌザヌステヌトは小さく明確に保ち、クリック埌に䜕が倉わるのかを正確に決めおください。ハンドラはトヌクンの目的、有効期限、䜿甚枈み状態を怜蚌し、成功時にただひず぀のステヌト倉曎だけを適甚したす。すでに完了しおいる状態ならフレンドリヌな確認を衚瀺しお先ぞ進めるようにしおください。

How can I implement these flows in AppMaster without writing custom backend code?

トヌクンず送信ログを別テヌブルずしおモデル化し、生成・怜蚌・消費・有効期限チェック・レヌト制限を䞀぀のBusiness Process内で実行するず、怜蚌・招埅・マゞックリンクで䞀貫した挙動を保おたす。クリック時の凊理を原子的にするこずで、トヌクンを消費せずにセッションを䜜る、たたはセッションを䜜らずにトヌクンを消費する、ずいった䞍敎合を防げたす。

始めやすい
䜕かを䜜成する 玠晎らしい

無料プランで AppMaster を詊しおみおください。
準備が敎ったら、適切なサブスクリプションを遞択できたす。

始める
機胜するトランザクションメヌルフロヌトヌクン、䞊限、配信 | AppMaster