留意点

URLクエリパラメータに機密情報を送信しないでください

LINK APIへのリクエストでは、アクセストークン、リフレッシュトークン、クライアントシークレットなどの機密情報をURLクエリパラメータで送信しないでください。URLはサーバーログに記録されることが多く、これはURLパラメータとして送信された機密情報が第三者に漏れる可能性があることを意味します。

その代わりに、OAuth 2.0標準ドキュメントRFC 6749セクション2.3.1およびRFC 6750セクション2.3で定義されているように、リクエストボディに機密性の高い値を送信してください。

📘

認証 code を URL パラメータで送信することは安全ですか？

認可要求の開始経由でLINK APIの認可フローを開始する場合、レスポンスはURLパラメータにcodeを指定してサーバにリダイレクトされます。これは code だけではアクセストークンを取得できないので安全です。これは client_secret (バックエンドサーバからリクエストする場合) または PKCE code_verifier (ウェブアプリケーションからリクエストする場合) を必要とします。

削除されたオブジェクトについて

Moneytreeの利用者はいつでも登録している情報を削除することができます(ゲストユーザーは、登録した金融サービスを削除することができます、また金融機関によっては、Open APIで金融機関が提供している設定機能などから、連携する科目を選択・解除することができる場合もあります。)。したがって、ある時点でAPIで取得できたデータであっても、それ以降にゲストが削除した場合は同じデータが取得できない可能性があります。

MoneytreeはIDを含め、削除されたオブジェクトを保存しません。こうしたデータを考慮したシステムを実装する必要があります。

例えば、個人口座APIをリクエストしても、以前存在したアカウントオブジェクト(Account)がレスポンスの配列に存在しない場合があります。
こうしたオブジェクトは、同様に実装するシステムにおいて削除する、または、ゲストの画面には表示しないなど、適切な実装をおこなってください。

なお、取引明細データ(各/transaction.json API)、および残高データ（各/balances.json API）などの各レコードについては、Moneytreeが自動的に取得するデータであり、原則一度記録されたレコードは削除されることはございませんが、稀に正しくないデータなどが誤って取り込まれた場合などは削除されることがあります。

同時アクセス数の制限について

同じ送信元から1分以内に膨大なAPIアクセスが発生した場合、HTTP Statusコードで、429が返されます。
しかし、想定せず429を受け取る場合は、Moneytreeにお問い合わせください。
なお、特定のAPIによっては、大量のアクセスがない場合でも429が返されることがあります。

APIの並行処理について

APIのコールは、同時に複数のリクエストを並行してリクエストすることを推奨します。例えば、あるゲストの口座に4件の取引明細(Transaction)があり、これら4件をのデータを取得する場合です。

次1件ずつコールする場合、以下の流れになります：

GET /link/v1/accounts.json
==> [Account ID 1, Account ID 2, Account ID 3, Account ID 4]

GET /link/v1/accounts/1/transactions.json
==> [500 Transactions]
GET /link/v1/accounts/1/transactions.json?page=2
==> [100 Transactions]
GET /link/v1/accounts/2/transactions.json
==> [100 Transactions]
GET /link/v1/accounts/3/transactions.json
==> [0 Transactions]
GET /link/v1/accounts/4/transactions.json
==> [10 Transactions]

各レスポンスに、ネットワークのレイテンシーを含めて100ミリ秒かかった場合、この方法では、処理が完了するまでに600ミリ秒かかることになります。これはゲストにとって、長く感じてしまう可能性があります。

MoneytreeのAPIは、同一のゲストから複数のアクセスに対応しているため、以下のような実装がより効率的です。

GET /link/v1/accounts.json
==> [Account ID 1, Account ID 2, Account ID 3, Account ID 4]

# ４つのリクエストを同時にスタートさせる
GET /link/v1/accounts/1/transactions.json
GET /link/v1/accounts/2/transactions.json
GET /link/v1/accounts/3/transactions.json
GET /link/v1/accounts/4/transactions.json

# ６行目のリクエストが返されたらこちらがリクエストされる
GET /link/v1/accounts/1/transactions.json?page=2

それぞれのリクエストのレスポンスが同程度だとした場合、この方法では300ミリ秒程度であり、半分の時間で処理が完了することが期待されます。
こうした並列的な処理は、順次リクエストする場合に比べ、やや複雑な実装になるかもしれませんが、ゲストの増大に対してよりスケーラブルで、よりメンテナンスが容易な構成になることが期待されます。

start、endとsinceの引数について

各Transactions APIエンドポイント (reference)には、start、end、そしてsinceのパラメータがあります。

startおよび、end はいずれもdate に対し比較されるものです。例えば、2015年7月2日に発生したトランザクションは、startおよび、end をそれぞれ2015-07-01、2015-07-02と指定された場合に返されることになります。

これに対し、sinceは、updated_atに対し比較されます。例えば、トランザクションがdate が 2010-01-01のものであっても、ゲストが2015-07-02にそのトランザクションに対し、description_guest属性を変更した場合は、sinceを、2015-07-02とセットすれば返されます。

一方で、実際のトランザクションとシステム間において発生しうる、二つの遅延について認識する必要があります。
1つ目は、実際のデータが、トランザクション内容に、即座に反映されるとは限らないことです。例えば、ある日に、ゲスト様がクレジットカードをレストランで利用したケースを考えてみます。クレジットカードによって異なりますが、クレジットカード会社により、数日から、場合によっては一ヶ月もレストラン名が表示されない場合もあります。

２つ目は、マネーツリーがそのデータを取得する（アグリゲーションする）タイミングです。上記の場合、実際のデータがクレジットカードの会員ページに反映された後でも、マネーツリーがそのデータをタイムリーに更新取得していない可能性があります。
（強制的に更新する方法については、Request Refresh APIを参照ください。）

以上より、例えば、2015-08-02に、startを2015-07-01、endを2015-07-31 とセットしてリクエストした場合でも、この期間の全てのトランザクションを取得できるとは限りません。結果として、ゲストがクレジットカードを7月31日、またはそれより前に利用した場合でも、クレジットカード会社のサイトまたはマネーツリー側でそれ以降何日か経過してもデータが入手されないことが発生し得ます。

こうした問題を対応するために、sinceは有効です。sinceは、指定した日以降のupdated_atの「トランザクション全てを返します。
新しく作成されたトランザクションはupdated_atが同じになります。また、上記の例においては、マネーツリーが7月31に発生したトランザクションを8月4日に取得したものは、sinceを2015-08-04とした場合でも取得できることになります。