Webhook
掲載内容以上のサポートはできません。
ご利用にあたっては十分なご理解の上で活用ください。
SuperSaaSは開発中を含むwebhookとAPIを提供するもので、それを利用するサービス、アプリケーションに責任を持つことはできません。
WebhookはSuperSaaS上のアカウント内で発生したユーザー定義のコールバックを、ほぼリアルタイム通知しており、他のアプリケーションやWebサイトでフックして活用できます。
新しいユーザー登録や、予約更新などのイベントのコールバックをフックして、チャットメッセージを送信するなどスケジュールの機能を拡張することが可能です。
webhookサービス
外部サービスを利用することで、構築の手間を省けるかもしれません。
Webhookは、Zapier.com や Make.comなどのサービスを利用することでプログラミングを必要とせずに構成することができます。
サービスが提供する機能をカスタマイズすることで、SuperSaaSのWebhookを別のサーバに直接送信することもできます。
webhookの外部サービスとの連携に関しては、SuperSaaSを他サイトへ接続を参照ください。
webhookの設定(自己構築)
この機能は、有料パッケージのご契約で利用可能となります。(試用中でも1週間の限定利用が可能です)
アカウント内のwebhook画面でwebhookを作成できます。
Webhookはイベントをトリガーとして発信するのみですので、その情報を受け取りアクションを行う外部のWebサービスが必要です。
一般的にはスクリプトやアプリケーションのサービスですが、webhookを受け取ることのできるウェブサイトでも利用できます。
ZapierやMakeを使用せずにWebhookを活用するには、Web開発のスキルが必要です。
このセクションでは開発者用のWebhook情報を掲載しています。
SuperSaaSが提供できる内容はこのセクションの情報のみとなりますので、開発される場合は十分な理解の上、自己責任での運用を願います。
Webhook発信内容のカスタマイズ
デフォルトではJSON形式でエンコードされた、全ての関連フィールドを送信します。
対象にカスタムフォームが添付されている場合、そのフォームも含まれます。
関連フィールドを全て送信しないことも可能ですし、あるいは、別途の定義フィールドを送信することもできます。
たとえば、APIキーや認証情報を内容に含めるなどが可能です。
新規Webhookを作成時に、送信するペイロード編集画面になります。
オプションの を選択している場合は、内容をカスタムでき、特定のフィールドを追加や削除が可能なJSONエディタが表示されます。
そこには、有効になっているフィールドに合わせて、メッセージが生成された時に置き換えられる利用可能なジックワードの情報が付記されていますので、それらを利用することも可能です
webhookのテスト
webhookをデバッグするのに役立つ良いウェブサイトにRequestBinがあります。
このサービスでは、ターゲットURLとして使用できるリンクが提供されているため、どのデータが送信されているかを正確に監視できます。
また、Webhookの編集画面のTestから、自動的なwebhook発信を停止し、手動でwebhookを発信することができます。
実際にスケジュール上などでイベントを生成させることなく、webhookを発信してテストできます。
トリガーされたテストメッセージは、平均して約5秒後に発信されます。
「OK」(200〜300の範囲外のステータスコード)ではないステータスコードが返る場合、およそ同じだけ待機して繰り返しリトライします。
5回以上失敗したメッセージは停止しますので、手動で再度発信してください。
10回の失敗でメッセージが削除されます。
ステータスコード410 (Gone)
が返る場合、webhookは直ちに削除されます。
メッセージキュー
Webhookメッセージがすぐに送信できない場合など、保留や待機中の全てメッセージのキューリストを表示するリンクが提供表示されます。
メッセージキュー画面では次回のリトライ試行情報が表示され、虫眼鏡アイコンをクリックすることでメッセージの内容を確認できます。
発信トリガー
トリガーとなるイベントは多数ありますが、主なものとして「新規登録」や「更新」、「削除」イベントなどがトリガーとなります。
「更新」イベントは、同時に「新規登録」や「削除」など連携するイベントがトリガーとなる場合もあります。
たとえば、「新規ユーザー登録」であれば、「新規登録」とユーザー情報「更新」の二つのトリガーが発信されることになります。
また、アカウントやスケジュールの設定で、利用できないトリガーもあります。
たとえば、ログインの必要のないスケジュール上では、ユーザー情報に関するイベントが発生しないため、それらをトリガーとすることはできません。
トリガー | 概要 |
---|---|
新規ユーザー登録 | 新規ユーザー登録がトリガーとなります |
ユーザー情報の更新 | ユーザー情報の更新がトリガーとなります |
新規予約の登録 | 予約の登録がトリガーとなります |
予約の更新 | 予約の更新がトリガーとなります。 更新には「新規登録」、「削除」、「キャンセル待ちリストからの移動」、「支払い」などステータス的な変更も含まれます。 (下記のeventフィールド情報も参照ください) |
スタンドアローンフォームの登録送信 | スタンドアローンに用いられているフォームでの登録がトリガーとなります。 フォームが予約に帰属するなどスタンドアローンな利用でない場合はトリガーとなりません。(帰属先の更新がトリガーとなります) |
スタンドアローンフォームの情報更新 | スタンドアローンに用いられているフォームの登録情報の更新がトリガーとなります。 こちらもスタンドアローンな利用でない場合はトリガーとなりません。(帰属先の更新がトリガーとなります)") |
メールの発信 | アカウントからのメール発信がトリガーとなります。(発信される全てのメールが対象のトリガーです) こちらも参照ください: 独自のメールサーバーの利用 |
リマインダー フォローアップ | リマインダー、フォローアップのイベントトリガーです。 webhookが有効である場合、リマインダー、フォローアップは発信されません |
購入 | ユーザーによるショップでの購入処理がトリガーとなります。 管理者はトリガー対象外ですが、ユーザーとして代替操作している場合はトリガーとなります。 |
eventとroleフィールド
イベントトリガーを特定するために、デフォルトのフィールドに含まれるイベントやロールを評価することができます
たとえば、管理者ではなくユーザーによって予定が削除された場合にのみメッセージを送信するなど、フィルタ処理することができます。
eventとroleフィールドに関しては下の表を参考ください。
トリガー | 指定可能なeventフィールド値 |
---|---|
新規ユーザー登録 | new |
ユーザー情報の更新 | new, change, delete |
新規予約 | create |
予約の更新 | create, edit, place, pending, destroy, restore, approve, revert |
スタンドアローンフォームの登録送信 | new |
スタンドアローンフォームの情報更新 | new, change, delete, restore |
リマインダー / フォローアップ | reminder, follow_up |
購入 | Purchase |
roleフィールド | トリガーとなる対象 | |
---|---|---|
0 | 匿名ユーザー | ログイン情報なし |
1 | シェアパスワードによるログイン | |
2 | IP制限をクリアしてのログイン | |
3 | 一般ユーザー | |
4 | Superuser | |
5 | 管理者、もしくは、リセーラー | |
7 | SuperSaaSシステム、もしくはペイメントシステム |
statusフィールド
支払いを含む予定を作成または変更するときは、「status」もしくは、「status message」フィールドを評価して、ステータスコードから特定のイベントを絞り込むことができます。
たとえば、「払い戻された予約」のstatus情報にのみトリガーをフックするなどフィルタリングに用いることが可能です。
APIのコール時に、
webhook = true
をパラメータとして追加することで変更できます。