SuperSaaSのAPI活用例を紹介

APIの活用例

実装もしくは公開されているSuperSaaSのAPIは、正直中途半端で実利的な活用が難しいと感じますが、それでも、いろいろと便利に使えます。

APIはデータベースへ直接SQLを送るイメージですので、データベースやSQLの基礎知識があると理解が早いと思います。

取り扱われる情報が個人情報ですし、サンプルソースの公開などは色々と問題もありますので概念的なものとなりますが、フリーランスとして相談を受けた時の事例など、実際の活用例などを交えて紹介します。

くれぐれもAPI利用は管理者権限で、セキュリティポリシーを十分に整えて開発運用ください。

SuperSaaSのAPIを活用するということは、アカウント内に蓄積されているデータに直接触れることになります。予約システムだけに、そのデータのほとんどが保護されるべき個人情報でしょう。

開発や運用が管理者自身であるなら自己責任において問題ありませんが、第三者に委託する場合は、情報保護などとてもデリケートになります。

悪意の有無にかかわらず情報の外部流出や不正利用などはもってのほかですが、そもそもAPIを用いるソースコードや環境にセキュア性が加味されていないという、危険な実装や運用事例などを見かけることがあります。

ユーザーAPIの活用例

ユーザーAPIは、ユーザー情報に対して基本的な機能（照会、登録、更新、削除）が一通りそそっているので色々と活用しやすいAPIです。

ユーザーAPIが扱う情報は個人情報そのものなので、十分なセキュリティ意識を持って設計運用しましょう！

ユーザー情報の連携利用

運用中のサイトや業務プラットフォームにユーザー情報がすでにあり、利用者がそこにログインしてSuperSaaSと連携している場合など、SuperSaaSに改めてユーザー登録し、あまつさえ二重にその情報を管理するのはナンセンスです。

サイトや業務プラットフォームのユーザー情報とSuperSaaSのユーザー情報は連携同期していることがベターです。

SuperSaaSのユーザーAPIは、ユーザー情報の「登録（INSERT）」、「更新（UPDATE）」、「削除（DELETE）」が可能です。
サイトや業務プラットフォームでのユーザー情報の「登録」、「更新」、「削除」をトリガーに、その処理をそのままSuperSaaSのユーザー情報にも行うことで、ユーザー情報の連携を実現することができます。

SuperSaaSのユーザー情報には外部キーの設定ができるため、親となるサイトや業務プラットフォームのユーザー情報のIDをあてることも可能です。
（IDが数字でないなど特殊な場合は流石に無理かもしれません・・・）

シームレスな連携を実現するAPIを用いたログイン例

ユーザーAPIにはログイン用のAPIがあります。
これは、ユーザー名（ログイン名）とユーザーパスワードを添えて、ログインした状態でスケジュールに遷移するAPIです。

独自システムからSuperSaaSを利用する場合、利用者が逐一のログイン操作を行うことなくシームレスな連携を実現できます。

アクセスコントロールで自身のサイトでログインとユーザー登録を管理とすることで、オープンなログインを抑制できますので、ログインに対してセキュリティ性を求める利用を希望する場合にもオススメの手法です！

ユーザー管理システムの独自構築

SuperSaaSのユーザーマネジメントで用意されている機能は、UIが汎用的で使い勝手に不足を感じるのでであれば、ユーザーAPIで独自にユーザー管理を行う仕組みを構築することを提案できます。

ユーザーAPIでユーザー情報の「登録（INSERT）」、「更新（UPDATE）」、「削除（DELETE）」ができますし、「照会（SELECT）」も可能です。

ニーズに合わせた機能や、スタイリッシュなUIにするなど色々とカスタム構築することが可能です。

ただし、現状ではカラム名を指定した評価（「WHERE カラム名 = 」や、「WHERE カラム名 LIKE 」）の機能は無いようです。
また、ソート（ORDER BY）もユーザー名の昇順で固定されているようで任意の指定はできません。

条件抽出やソートは情報取得後に処理することになります。

もしかしたら、公開されていないだけで隠しメソッドがあるかもしれません。

アポイントAPIの活用例

リソーススケジュールは予約情報に対して「照会（SELECT）」、「登録（INSERT）」、「更新（UPDATE）」、「削除（DELETE）」可能です。

定員制スケジュールも予約情報に対しては可能ですが、スロット情報に対するAPIはありません。

サービススケジュールはなぜか不遇で、「照会」と「削除」のみ可能です。

正直、ちょっと実装が中途半端に感じます。
個人的には、APIでスロット情報の編集が可能になれば、登録の自動化とかしないで良くなるので期待してます。

自動バックアップ例

履歴データの蓄積には上限があるので、過去の予約は自動的に削除する設定で運用している場合がほとんどと思います。
また、およそ予約情報はバックアップしてSuperSaaS外で保管している場合も多いでしょうし、その手段はダウンロードから手動でダウンロードしていると思います。

そこで、CRONなど定期処理でAPIを用いることで、バックアップの自動化が設計可能です。

ダウンロードやウェブフックや外部サービスを用いることでもできることですが、APIならよりダイレクトに独自の仕様でデータを処理できる点が利点です。

ワンクリック予約例

予約時に必要な情報がすでに存在する前提ですが、アポイントAPIの「登録（INSERT）」を用いて、ワンクリックで予約の実行が実装できます。

スケジュールにアクセスして、予約対象を選択して、新規予約をクリックして、登録内容を入力して…などの操作を簡略化できます。

意外に予約操作って手間がかかりますので、定型のエントリーなど単純な予約実行の実装に便利です。

同時予約例

ワンクリック予約の派生的な使い方ですが、予約の「登録」の向き先を複数にすることで同時予約の実装も可能になります。

AとBとCを一度に予約とか、Aを予約すると同時にBやCも予約するなど、応用ができます。

実際には同時予約が可能かどうか判定するなど、例外処理なども仕組みに取り入れる必要があります。

分析利用例

予約情報を取得分析して、統計データを作成するツールに活用できます。

アカウント全体、スケジュールごと、ユーザーごと、年ごと、月ごとなど、予約情報の分析データをもとに、予約率や利用率、時間帯稼働率など様々な統計データに使える分析用のデータ取得処理に用いることができます。

リアルタイムにAPIを用いて行うほどのものかどうか疑問です。
過負荷を考えると、取得こそAPIを用いた定期処理にするとしても、分析や統計処理はオフラインで行うことが推奨されると思います。

フォームAPIの活用例

非常に残念なことに、フォームAPIはなぜかフォームデータの「照会（SELECT）」のみの実装です。
「登録（INSERT）」、「更新（UPDATE）」、「削除（DELETE）」はできません。

ユーザーAPIやアポイントAPIの「照会」時の副問い合わせ的に自動的に用いられる以外、基本、単体での利用はあまりないように感じます。

ユーザー情報、予約情報に紐づくものだけでも編集メソッドの実装や、副問い合わせのメソッドの実装が切望されます…

分析利用例

投稿されたフォーム情報を取得分析して、統計データを作成するツールに活用できます。
フォームをアンケートなどに利用している場合などには重宝すると思います。

当然ながらリアルタイムな統計などは過負荷の懸念から推奨しません。
もちろん目的やニーズにもよりますが、分析や統計処理はオフラインがベターに思います。