ポイント更新API
弊社システムとスマレジでポイントの同期連携を行うことを考えています。
ポイントの操作（追加・削除・失効）が行われた際、取引データとして
登録されるかと思いますが、この取引データがAPIで登録されたものなのか
スマレジで登録されたものなのかを判別する方法はないでしょうか。
以下のフローを実現するために、Webhookで通知されたポイント更新通知について
更新元がAPIなのか、スマレジなのかを判別できないため、弊社ステムでポイント操作を行った際
Webhookにて通知時に二重でポイント操作が発生してしまうため、連携処理方法を模索しています。
・スマレジでポイント操作 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成
・弊社システムでポイント操作（操作ポイントの履歴も作成） → APIにてポイント更新 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成
Webhookにて通知のあったポイント更新が、APIによるものなのかスマレジでの操作なのかが判別できれば
二重のポイント処理はクリアできるかと思います。
その為、ポイントの操作（追加・削除・失効）の取引データで更新元を判別するか
もしくは、ポイント更新のAPIのレスポンスで取引IDを返していただけると判別できるかと思いますが
今後、そういったものの対応の予定はございますでしょうか。
答え
@福島
この取引データがAPIで登録されたものなのか
スマレジで登録されたものなのかを判別する方法はないでしょうか。
ございません。
Webhookは特定のアクションが実行されたときに通知するシステムで、そのアクション毎に判別するものをもたせる予定は現状ありません。
ここで質問でございます。
Webhookにて通知のあったポイント更新が、APIによるものなのかスマレジでの操作なのかが判別できれば
二重のポイント処理はクリアできるかと思います。
こちらで二重のポイント処理となってしまうのを防ぐという箇所での問題点というのは
自身のアプリで更新した後、APIで更新されたことを検知したWebhookで再度、更新が走ってしまうということで相違ないでしょうか？（別の問題についての議論であればご指摘下さい）
以下、個人としての見解とご提案です。
問題点が上記であっていれば、
弊社システムでポイント操作（操作ポイントの履歴も作成） → APIにてポイント更新 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成ではなく、最初の処理を省略して、
APIにてポイント更新 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成で二重処理は回避できるかと思います。
設計思想的にそれが望ましく無いのであれば、自身のアプリでの更新とWebhook更新での二重処理を許容する他ないのでは。と思いました。
いかがでしょうか？
この質問については、詳細な問題点と、設計思想がわからなければ回答が難しいと思います。
できれば詳細伺いたいので、ご検討のほどお願いします。
Webhookは特定のアクションが実行されたときに通知するシステムで、そのアクション毎に判別するものをもたせる予定は現状ありません。
承知しました。
会員ポイントAPIのレスポンスについても、取引IDが返されるようにする予定はないでしょうか。
ご質問の件は、ご認識の通りです。
ご提案頂いた、
APIにてポイント更新 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成ですが、Webhook通知にて弊社システムのポイント同期を行うとすると、実際ユーザがポイント操作を行ってから
通知が来て更新されるまでにタイムラグが生じてしまいます。
さらに、弊社のアプリはWindowsFormアプリの為、Webhookは一旦弊社のWebサーバで受けて通知情報を保持した上
WindowsFormアプリから弊社Webサーバへ通知の問合せを行う仕組みになっており、タイムラグが大きくなってしまいます。
また、弊社システム側で取引を発生させた場合のポイント増減については別管理になっており
Webhookで受けた、会員ポイント更新通知が
「スマレジでの手動ポイント操作による更新なのか」、「弊社システムでの手動ポイント操作による更新なのか」、
「弊社システムでの取引発生時のポイント更新なのか」を判別する必要があり、ご提案の方法では、難しいと思われます。
現状の仕様ですと、スマレジ側からの会員ポイントの手動更新がネックになってくるため
「スマレジ側ではポイントの手動更新は行わない」という運用制限を設ける他ないかと考えております。
（弊社システム内でポイント更新を行い、APIにてスマレジのポイント更新は行うが、Webhookによりポイント更新はすべてスルーする）
@福島
結局、二重のポイント処理というのは難しい。ということで間違いないでしょうか？
お話を聞く限り、整合性重視の設計ですので、アプリ側の操作も、スマレジ側の操作も両方とも信頼すればいいように思えました。（的外れでしたら申し訳ありません。）
「スマレジでの手動ポイント操作による更新なのか」、「弊社システムでの手動ポイント操作による更新なのか」、
「弊社システムでの取引発生時のポイント更新なのか」を判別する必要があり
とありますが、スマレジ側のとのポイントの完全同期を図るなら、どのイベントか？というのはあまり重要では無いかと思いますが、いかがでしょうか？
私が二重のポイント処理の問題点についてまだ理解出来ていないので、もし私が勘違いしているようであればご指摘ください。
（また、前回の質問でも伺っておりますが、自身のアプリで更新した後、APIで更新されたことを検知したWebhookで再度、更新が走ってしまうということで相違ないでしょうか？（別の問題についての議論であればご指摘下さい））
よろしくお願いいたします。
返信ありがとうございます。
説明が足りておらず、申し訳ありません。
問題点として、ポイントの更新についてはアプリ側で更新したか、スマレジ側で更新したかは
「会員のポイント」という1つの項目に対して、絶対値で更新していくので、特に問題ないかと思います。
問題となるのは、ポイントの増減履歴についてです。
先ず当初の
弊社システムでポイント操作（操作ポイントの履歴も作成） → APIにてポイント更新 → Webhook通知 → 弊社システムでポイントの同期及び・操作ポイントの履歴作成で処理を行うと、ポイント増減履歴データが二重で登録されてしまいます。
ご提案頂いた方法ですと、履歴が二重で登録される問題はクリアできますが
「スマレジでの手動ポイント操作による更新なのか」、「弊社システムでの手動ポイント操作による更新なのか」、
「弊社システムでの取引発生時のポイント更新なのか」を判別する必要があり
が判別できないと、弊社側でアプリ上で登録した取引にて発生したポイントの増減が、弊社アプリ側ですべて手動更新した履歴になってしまうため
不都合があります。（この辺りは弊社のアプリの作り、ロジックの問題でもありますが）
また、通常のWebアプリとは違いポイント更新に大きなタイムラグが出てしまう為、不都合があります。
自身のアプリで更新した後、APIで更新されたことを検知したWebhookで再度、更新が走ってしまうということで相違ないでしょうか？
この認識で相違ありません。ただ、更新というよりも履歴の「追加」登録といった方が正しいかと思います。
@福島
なるほど、履歴でしたか。申し訳ありません。見落としていました。
確かに、それだとおっしゃるとおりの動作になってしまいます。
それに加え、アプリ側の操作を無視してWebhookで更新するとおかしくなるという件についても理解いたしました。
履歴を残す際にどこの操作でという情報を正確に読み取りたいニーズがあるということですね。
申し訳ありません。
この件についてはデベロッパーズチームとスマレジPOSチームで協議をしたのですが、明確な代替案や解決案を出せていません。
また、「管理画面 / API」に関わらず、「Webhookを通知」するという仕様は変更出来ません。
最後に、Webhook時にどのアクションで通知されたかという項目を追加するですが、この実装については今回の@福島 様のユースケースが在ることを考慮し、持ち帰らせていただきます。しかし、すぐに実装・解決というのは難しいと思います。
ネガティブな回答になってしまい申し訳ございません。
よろしくお願いいたします。