組織、アプリケーション、環境
組織はチームと請求を保持し、アプリケーションはワークフローとAPIキーを保持します。それぞれが本番かサンドボックスのいずれかです。この構造を正しく理解しておくことで、多くの紛らわしい挙動を防げます。
組織＝あなたのチーム、請求残高、監査ログです。
アプリケーション＝ワークフロー、APIキー、webhookの送信先、保持ポリシー、そしてliveまたはsandboxというモードです。「変更したのに何も反映されない」という問題のほとんどは、アプリケーションを間違えていることが原因です。
#2つの階層
組織はあなたのアカウントです。以下を保有します。
- チームとそのロール
- 請求残高と請求書
- 監査ログ
- すべてのアプリケーション
アプリケーションは組織内のワークスペースです。以下を保有します。
- 独自のワークフロー
- 独自のAPIキー
- 独自のwebhook送信先
- 独自のデータ保持ポリシー
liveまたはsandboxというモード
コンソール上部のドロップダウンでアプリケーションを切り替えられます。
#これが見た目以上に重要な理由
「変更したのに何も起きなかった」という報告のほぼすべてが、この構造に行き着きます。
- セッションはアプリケーションBで動いているのに、アプリケーションAのワークフローを編集した。
- あるアプリケーションにwebhookの送信先を追加したのに、別のアプリケーションからのイベントを期待していた。
- 呼び出そうとしているリソースとは別のアプリケーションのキーで呼び出しており、明らかに存在するはずのものに対して404や403を受け取っている。
他の何かをデバッグする前に、まずアプリケーションを確認してください。APIエラーとその意味をご覧ください。
#本番とサンドボックスは別々のアプリケーション
本番アプリケーションの中にテストモードの切り替えはありません。モードはアプリケーションごとに選択されるため、テストとは、サンドボックスモードで2つ目のアプリケーションを作成し、そのキーを使うことを意味します。
この分離こそが重要な点です。テストトラフィックと本番データが混ざることは決してなく、サンドボックスキーが誤って実際のクレジットを消費することもありません。サンドボックスでのテストをご覧ください。
アプリケーションには、一目で混同しない名前を付けてください。「Application」「Application (2)」よりもacme-liveやacme-sandboxのほうが優れています。シークレット管理システムでも対応する名前でキーを保管し、「現在有効なほうのキー」を1つの環境変数に持たせるようなことは避けてください。
#いくつアプリケーションを持つべきか
最低でも本番用が1つ、サンドボックス用が1つです。それ以上は、独自の設定や独自の分離が必要なものごとに分けてください。
- 製品ごと。異なる製品が異なるワークフローと異なるwebhookエンドポイントを必要とする場合。
- 環境ごと。複数のプレプロダクション環境を運用している場合。
- ブランドごと。複数のブランドで異なるスタイルの検証を提供している場合。
- 保持ポリシーごと。保持ポリシーはアプリケーションごとに設定されるためです。
アプリケーションごとに分かれないものは残高です。これは組織レベルであり、すべてのアプリケーションが同じクレジットを使用します。
#追加のアプリケーションを作成する
追加のアプリケーションはコンソールで作成します。選択肢が見当たらない場合や、コンソールではなくAPI経由で作成する必要がある場合、それはアカウントレベルの権限の問題であり、自己判断で回避するのではなくサポートに確認する価値があります。特に2つ目の本番アプリケーションについては、プランに関わる話になることがあります。
#複数の組織
1人のメールアドレスは一度に1つの組織にしか所属できず、自分の組織の下にサブ組織やサブアカウントを作る方法はありません。自社の複数の顧客にサービスを提供する場合、サポートされる構成は1つの組織の中で顧客ごとに1つのアプリケーションです。各アプリケーションは独自のワークフロー、ブランディング、APIキー、結果、利用レポートを持ち、他から完全に分離されますが、請求は組織レベルにまとまります。
#Diditの再販
Diditを自社製品に組み込み、顧客に課金したい場合、それがリセラーモデルです。サポートが問い合わせた全員に伝えている条件は次の通りです。
- 前払いクレジット。 最低初回購入額は5,000米ドル、前払い、1年契約です。クレジットは失効せず、組織レベルに置かれ、あなたが獲得したすべてのエンド顧客で消費され、金額に応じて深くなるボリューム割引が付きます。
- ダッシュボードはあなたが構築します。 DiditのAPIを自社のフロントエンドに組み込み、顧客はそこでワークフロー、ブランディング、ロールを管理します。DiditはBusiness Consoleのホワイトラベル版を提供しません。エンドユーザーが見る検証画面にはあなたのブランドを付けられます（ホワイトラベルを参照）が、コンソールには付けられません。
- マージンはあなたのものです。 顧客が支払う価格はあなたが決めます。Diditは契約期間中固定の単価で、完了した機能ごとにあなたに請求します。
- ローカルパートナープログラムではありません。 Diditはデモ、オンボーディング、サポートを顧客と直接行っており、販売代理店や導入パートナーは募集していません。
再販を自分で扱いたくない場合は、代わりに紹介オプションを使ってください。Business Consoleのサイドバーで紹介を開き、プログラム規約に同意してリンクを共有します。紹介した組織が行うすべての現金入金に対して10%のコミッションを、初回入金から36カ月間受け取れます。Diditクレジットとして使うか、熟成期間後に銀行振込で受け取れ、納品やサポートの義務はありません。どちらに決める前でも、無料枠で連携を構築・テストできます。
#アプリケーションの削除
アプリケーションを削除すると、そのワークフローと設定が削除されます。検証データについては、アプリケーションのライフサイクルではなく、そのデータに対する保持ポリシーと削除ルールに従います。つまり、顧客データを消去したいのであれば、アプリケーションを削除すれば済むと思い込まず、データそのものを明示的に削除してください。セッションと個人データの削除をご覧ください。
#すべてに帰属先がある
すべてのAPI呼び出しは、どのアプリケーションに属するかを監査ログに365日間記録します。これが、複数アプリケーション構成を単に整理されたものにとどめず、監査可能なものにしています。監査ログの利用をご覧ください。