リアルタイム デベロッパー通知(RTDN)
Aptoide Connect のリアルタイム デベロッパー通知(RTDN)を使用すると、開発者は、サブスクリプション型の商品の購入に関連する特定のイベントについて即時の更新を受け取ることができます。また、消費型商品とサブスクリプションに影響を及ぼす可能性のある無効化された購入についても通知します。
RTDN により、お客様の購入に関する情報を常に把握し、購入に対して行われたあらゆる変更にリアルタイムで対応できます。
概要
Aptoide Connect の RTDN サービスは、開発者に次の通知タイプを通知します。
- 一回限りの商品(消費型)の購入通知: 消費型商品タイプの購入が成功したときに送信される通知。
- サブスクリプション購入通知: サブスクリプションの状態に変化があったときに送信される通知。このセクションで サブスクリプションのライフサイクルの状態 を確認してください。
- 無効化された購入通知: 購入が無効化されたときに送信される通知。
これらの通知は、イベントに関する重要な詳細を提供し、記録の更新や必要な対応を行うことを可能にします。
これにより、ユーザーエクスペリエンスを目的とした次の点でアプリケーションを改善できます。
-
即時更新: リアルタイム通知により、サブスクリプションの変更(更新やキャンセルなど)が発生するとすぐにユーザーに通知されます。
-
信頼性の向上: 最新のサブスクリプション情報により、ユーザーは正確な請求とサブスクリプションのステータスについてサービスを信頼でき、プラットフォームへの信頼が高まります。
-
シームレスなユーザーエクスペリエンス: 最新のバックエンドデータにより、ユーザーは最新のサブスクリプション詳細を受け取ることができ、混乱や古い情報を回避できます。
-
バックエンドの同期: 開発者にとって、バックエンドを最新の状態に保つことで、RTDN を通じた正確かつ適時なデータ配信が保証され、サブスクリプション管理における遅延や不整合などの問題を防ぎます。
RTDN API の設定
RTDN の受信を開始するには、開発者はコールバック URL を登録する必要があります。この URL は、Aptoide Connect のサービスがイベントを送信する先です。
1. コールバック URL を登録する
RTDN 用のコールバック URL を登録するには、Aptoide Connect の Webhooks ページにアクセスします。

図 1 - RTDN URL を登録する Webhooks ページ
このページに入ると、Add ボタンを使用して新しい URL を追加でき、受信したい通知のタイプを選択できます。
RTDN で受信できる商品タイプは 2 種類あります。
- Subscriptions: このオプションを選択すると、Aptoide Connect のサービスが Subscriptions タイプの商品に関連する通知を送信するようになります。
- InApp: このオプションを選択すると、Aptoide Connect のサービスが InApp タイプの商品に関連する通知を送信するようになります。

図 2 - RTDN URL の登録
2. コールバック URL を管理する
RTDN 用の URL を登録すると、次のオプションでそれを管理できます。

図 3 - Webhook の管理
通知ペイロード
受信する通知ペイロードは、base64 エンコード方式で data パラメータにエンコードされています。
{
"message": {
"attributes": {
"key": "value"
},
"data": "eyJ2ZXJzaW9uIjogIlN0cmluZyIsICJwYWNrYWdlTmFtZSI6ICJTdHJpbmciLCAiZXZlbnRUaW1lTWlsbGlzIjogIkxvbmciLCAib25lVGltZVByb2R1Y3ROb3RpZmljYXRpb24iOiAiT25lVGltZVByb2R1Y3ROb3RpZmljYXRpb24iLCAic3Vic2NyaXB0aW9uTm90aWZpY2F0aW9uIjogIlN1YnNjcmlwdGlvbk5vdGlmaWNhdGlvbiIsICJ2b2lkZWRQdXJjaGFzZU5vdGlmaWNhdGlvbiI6ICJWb2lkZWRQdXJjaGFzZU5vdGlmaWNhdGlvbiJ9",
"messageId": "123456789012"
}
}
data パラメータをデコードすると、次の JSON スキームのペイロードが見つかります。
{
"version": String,
"packageName": String,
"eventTimeMillis": Long,
"subscriptionNotification": SubscriptionNotification,
"voidedPurchaseNotification": VoidedPurchaseNotification
}
このペイロードのパラメータは次のように説明されます。
名前 | 型 | 説明 |
|---|---|---|
version | String | 受信したペイロードのバージョン。 |
packageName | String | 通知が対応するアプリケーションのパッケージ名。 |
eventTimeMillis | Long | このイベントが発生したタイムスタンプ。 |
oneTimeProductNotification | OneTimeProductNotification (nullable) | このパラメータが存在する場合、通知が消費型商品の購入における状態変化に関連していることを意味します。 |
subscriptionNotification | SubscriptionNotification (nullable) | このパラメータが存在する場合、通知がサブスクリプション購入における状態変化に関連していることを意味します。 |
voidedPurchaseNotification | VoidedPurchaseNotification (nullable) | このパラメータが存在する場合、通知が無効化された購入に関連していることを意味します。 |
各 通知タイプ が生成しうるペイロードについて確認してください。
通知の処理
イベントが発生すると、当社のサービスは登録されたコールバック URL に対して、JSON 形式の通知ペイロードを含む HTTP POST リクエストを送信します。
これらの通知を効果的に処理するために、次のプラクティスを実装してください。
-
200 OK ステータスコードで応答する:
- サーバーが受信を確認するために、通知に対して
200 OKHTTP ステータスコードで応答することを確実にしてください。 - イベントを確認するために、レスポンスボディに
"Event received successfully"などのメッセージを含めてください。
応答例:
{
"message": "Event received successfully"
} - サーバーが受信を確認するために、通知に対して
通知を処理するためのベストプラクティス
- 迅速に応答する: 確認応答として、通知エンドポイントに
200 OKHTTP ステータスコードで応答してください。これにより、通知が正常に受信されたことが保証されます。 - エラー処理: サーバーが利用できない場合やエラーを返した場合、当社のサービスは指数バックオフを用いて通知配信を複数回再試行します。
FAQ
コールバック URL をテストするにはどうすればよいですか?
サンドボックステストの仕組みを使用して購入を行い、その購入のイベントを受信してください。
サーバーがダウンしている場合はどうなりますか?
サーバーが利用できない場合、当社のサービスはバックオフアルゴリズムを使用して通知の送信を複数回再試行します。