先に業務注文を保存
一意のclient_order_idを作り、数量、期間、受取アドレスをデータベースへ保存します。一意制約で並行処理による重複を防ぎます。本記事は接続例であり、顧客実績ではありません。
正確な見積もりを保存
GET /prices/quoteには実際の数量と期間を使い、quote_id、金額、expires_atを一緒に保存します。整数SUNまたは精密な数値型を使い、条件変更時は見積もりを取り直します。
送信するバイト列に署名
鍵はサーバーだけに保管します。JSONを一度シリアライズし、仕様に従い実際の送信内容へ署名します。ログから鍵と認証ヘッダーを除きます。
冪等性キーも保存
POST /ordersにはclient_order_idに加え、8〜128文字の可視ASCIIからなるIdempotency-Keyが必要です。送信前にキーとリクエストの正確なバイト列を保存します。不確定な作成の再試行では両方を維持し、timestamp、nonce、署名だけを新しくします。以前の受理結果を確認してから期限切れ見積もりを更新してください。Webhook規則は公開Skillを参照し、通知のないアドレス有効化は照会で追跡します。
不確定な応答を照会
POST /ordersがタイムアウトしたら、GET /orders?client_order_id={client_order_id}で確認します。既存注文を追跡し、再試行が適切な場合も同じ番号と条件を維持します。冪等性の競合は調査対象です。
受理と完了を区別
プラットフォームの注文IDと状態を保存し、終端結果と提供の証拠からローカル状態を更新します。HTTP成功だけで委託済みにせず、失敗や確認待ちを残します。
通知の検証と重複排除
仕様に従いWebhook署名を検証し、イベントIDで重複処理を防ぎます。確実に保存または処理してから応答します。状態が食い違う場合は注文照会で照合します。
再試行と異常テスト
タイムアウト、上限付き指数バックオフ、有限の再試行回数を設定し、秘密を含まない履歴を記録します。残高不足、期限切れ、重複、受理後タイムアウト、不正署名を検証してください。実際の通信形式は公開仕様に従います。
開発者向け資料
公開API仕様とサーバー側の参考クライアントです。閲覧にログインは不要ですが、APIの利用には有効化済みアカウントが必要です。
https://api.tronow.io/openapi/v1
| HTTP | API |
|---|---|
GET | /prices/quote |
POST | /orders |
GET | /orders |
GET | /orders/{order_id} |
POST | /address-activations |
GET | /address-activations |
GET | /address-activations/{activation_id} |
GET | /account/balance |