APIとアウトバウンドウェブフックを開く

開発者アクセスを有効にし、ベアラキーで/api/v1を呼び出し、注文ライフサイクルイベントのためにアウトバウンドウェブフックを購読します。

APIキー、レート制限、発見、注文イベントウェブフック。

開発者アクセスを有効にする

設定→開発者を開き、アクセスを有効にし、APIキーとオプションのウェブフックエンドポイントを作成します。

  • キーはあなたのセラーアカウントにスコープされ、いつでも取り消すことができます。
  • オープンAPIトラフィックは、各セラーに対して1分あたり300リクエストに制限されています。
  • GET /api/v1は、利用可能なリソースの発見メタデータを返します。

APIを認証し、呼び出す

ライブシークレットキーでAuthorization: Bearerを送信します。HTTPSのみを優先してください。公開クライアントにキーを埋め込まないでください。

  • offers:read: オファーのリストを取得。
  • offers:write: オファーを作成、更新、公開、削除。
  • orders:read: セラーの注文をリスト取得。
  • orders:write: 注文を配達済みにマーク。

最近の注文をリストする

bash
curl -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1/orders

キーを回転させる

キーが漏洩した場合は、開発者設定で取り消し、新しいものを作成します。ライブの場合は、取り消す前に自動化を更新してください。

APIエンドポイントマップを開く

ベースパスは /api/v1 です。成功したレスポンスには X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset が含まれます。GET /api/v1 はこの記事に一致する機械可読の操作カタログを返します。

  • GET /api/v1: ディスカバリー(有効なキー)。
  • GET /api/v1/offers: オファーのリストを取得(offers:read)。
  • POST /api/v1/offers: ドラフトを作成(offers:write)。
  • GET /api/v1/offers/:urlOrId: オファーを取得(offers:read)。
  • PATCH /api/v1/offers/:urlOrId: オファーのフィールドを更新(offers:write)。
  • DELETE /api/v1/offers/:urlOrId: 削除またはアーカイブ(offers:write)。
  • POST /api/v1/offers/:urlOrId/publish: 公開(offers:write)。
  • GET /api/v1/orders: 売上をリスト取得(orders:read)。
  • GET /api/v1/orders/:uid: 注文を取得(orders:read)。
  • POST /api/v1/orders/:uid/deliver: 配達済みにマーク(orders:write)。

ライブ操作カタログを印刷

bash
curl -s -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1 | jq ".operations"

オファーAPI

オファー識別子は公開URLスラグまたは数値IDを受け入れます。レスポンスには内部IDとsellerIdは含まれません。ストック行、オプション価格、メディア、属性はセラーエディタ(または将来のエンドポイント)で管理され、まだPATCHでは行えません。

アクティブなオファーをリスト取得

bash
curl -H "Authorization: Bearer rmt_sk_live_…" "https://rmt.gg/api/v1/offers?archive=active"

ドラフトオファーを作成

bash
curl -X POST -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1/offers

関連情報付きのオファーを取得

bash
curl -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1/offers/YOUR_OFFER_URL

許可されたフィールドを更新

bash
curl -X PATCH -H "Authorization: Bearer rmt_sk_live_…" -H "Content-Type: application/json" https://rmt.gg/api/v1/offers/YOUR_OFFER_URL -d @body.json

許可されたPATCHボディフィールド

json
{
  "title": "更新されたタイトル",
  "description": "バイヤー向けの説明",
  "visibility": "PUBLIC",
  "categoryId": 12,
  "offeringId": 34,
  "thumbnail": "https://…",
  "offerType": "ACCOUNT",
  "listingMode": "STANDARD"
}

公開(デフォルトはPUBLIC)

bash
curl -X POST -H "Authorization: Bearer rmt_sk_live_…" -H "Content-Type: application/json" https://rmt.gg/api/v1/offers/YOUR_OFFER_URL/publish -d '{"visibility":"PUBLIC"}'

削除またはアーカイブ

bash
curl -X DELETE -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1/offers/YOUR_OFFER_URL

公開要件

必要なリスティングフィールドが不完全な場合、公開は400で失敗します(オファーエディタと同じ検証)。成功した更新は offer.updated webhook を発行することがあります。

注文API

注文はあなたのセラーアカウントにスコープされています。バイヤーの請求情報は削除される場合があります。取得と配達には公開注文UID(不透明な参照だけではなく)を使用してください。

最近の有料売上をリスト取得

bash
curl -H "Authorization: Bearer rmt_sk_live_…" "https://rmt.gg/api/v1/orders?status=PAID&limit=20&sort=newest"

ラインアイテム付きの注文を取得

bash
curl -H "Authorization: Bearer rmt_sk_live_…" https://rmt.gg/api/v1/orders/ORDER_UID

配達済みにマーク

bash
curl -X POST -H "Authorization: Bearer rmt_sk_live_…" -H "Content-Type: application/json" https://rmt.gg/api/v1/orders/ORDER_UID/deliver -d @evidence.json

オプションの証拠ボディ

json
{
  "evidence": [
    "https://cdn.example.com/proof-1.png"
  ]
}

エラーとレート制限

エラーはJSON { error, code? } を返します。レート制限はAPIキーごとに1分あたり300リクエストです。

  • 401 API_KEY_REQUIRED または API_KEY_INVALID。
  • 403 SCOPE_MISSING キーがエンドポイントスコープを欠いている場合。
  • 404 あなたが所有していないオファーまたは注文が見つかりません(どちらの場合も同じメッセージ)。
  • 429 RATE_LIMITED Retry-After と X-RateLimit-* ヘッダー付き。
  • 400 検証失敗の場合(公開不完全、配達不許可、空のPATCH)。

429の処理

Retry-After秒を使用してバックオフしてください。制限を回避するためにキーを回転させないでください; 制限はキーごとであり、すべてのセラーに対してフラットです。

アウトバウンド注文ウェブフック

order.paid、order.delivered、order.completed、order.refunded、order.disputedを購読します。サーバー用にJSONを選択するか、Discord用にチャンネル埋め込みを選択します。オプションの署名はX-RMT-TimestampとX-RMT-Signatureを使用します。

  • Discord形式は、注文リンクとオファー名を含むリッチ埋め込みを投稿します。
  • JSON形式は、オファー名とラインアイテムを含む構造化されたボディを投稿します。
  • 秘密を設定した場合、timestamp.bodyのHMAC-SHA256がv1=署名の16進数と等しいことを確認します。
  • 配達履歴は各エンドポイントの下に表示されるため、失敗を再試行できます。

例の署名ヘッダー

json
{
  "X-RMT-Event": "order.paid",
  "X-RMT-Timestamp": "1710000000",
  "X-RMT-Signature": "v1=abc123…"
}

署名を確認する

timestamp + "." + rawBodyの文字列に対してHMAC-SHA256を計算します。v1=の後の16進数と比較します。

Node.jsスケッチ

javascript
import crypto from "crypto";
const expected = crypto
  .createHmac("sha256", secret)
  .update(`${timestamp}.${rawBody}`)
  .digest("hex");
const ok = expected === signature.replace(/^v1=/, "");

開発者ツールを開く

設定でキーとウェブフックエンドポイントを作成します。