P2p

Binance P2P Trading Skill

Help users interact with Binance P2P (C2C) via natural-language queries.

When to Use / When NOT to Use

Use this skill when the user wants to:

• Check P2P buy/sell quotes for a crypto/fiat pair (e.g., USDT/CNY).
• Search P2P advertisements and filter by payment method(s), limits, merchant quality.
• Compare prices across payment methods (e.g., Alipay vs bank transfer).
• View their own P2P order history / summary (requires API key).
• Query order detail and view full order timeline (requires API key).
• Check appeal/complaint status and view complaint history (requires API key).
• Submit evidence for an existing appeal (upload files + submit description) (requires API key).
• View complaint process timeline (flow of actions, CS notes, evidence) (requires API key).
• Cancel an existing appeal (withdraw complaint, irreversible) (requires API key).
• View available complaint reasons for an order (requires API key).
• Publish, update, or manage P2P advertisements (requires API key + merchant permission).
• View merchant profiles and their ad listings (requires API key).
• Query supported digital and fiat currencies (requires API key).

Do NOT use this skill when the user asks about:

• Spot/Convert prices, futures/derivatives, margin, trading bots.
• Deposits/withdrawals, wallet transfers, on-chain transactions.
• Creating/cancelling orders, releasing coins (trading operations). Cancelling appeals (complaints) IS supported.
• Initiating new appeals (submit-complaint is deferred; evidence supplement for existing appeals IS supported).
• Sending chat messages in order conversations.

Ask clarifying questions (do not guess) if any key inputs are missing:

• fiat (e.g., CNY)
• asset (e.g., USDT)
• user intent: buy crypto or sell crypto
• preferred payment method(s)
• target amount (optional but recommended for ad filtering)

Core Concepts

tradeType mapping (avoid ambiguity)

• User wants to buy crypto (pay fiat, receive USDT/BTC) → tradeType=BUY
• User wants to sell crypto (receive fiat, pay USDT/BTC) → tradeType=SELL

Always reflect this mapping in responses when the user's wording is ambiguous.

Capabilities

Phase 1 — Public Market (No Auth)

• Quote P2P prices
• Search ads
• Compare payment methods
• Filter/Rank ads by limits and merchant indicators

Phase 2 — Personal Orders (Requires API Key)

• List P2P order history
• Filter by trade type / time range
• Provide summary statistics

Phase 3 — Order & Appeal + Ad Publish & Management (Requires API Key)

• Query order detail by order number
• List orders with rich filters (status, trade type, asset, date range)
• View order timeline (creation → payment → release → completion)
• Detect appeal status and show appeal details
• Query complaint/appeal records with filters
• Get market reference prices for pricing decisions
• Upload appeal evidence files (S3 presigned URL + submit)
• View complaint process timeline / flow details
• Cancel an existing appeal / withdraw complaint
• Get available complaint reasons for an order
• Search and analyze market ad distribution
• Get available ad categories for current user
• Get user's configured payment methods
• List all system trade methods
• Publish new advertisements (with confirmation)
• Update existing ad parameters (with confirmation)
• Update ad status: online / offline / close (with confirmation)
• View merchant profile and ad listings
• List all supported digital currencies
• List all supported fiat currencies

Environment Configuration

Base URLs (production)

Implementation hint (for code generation)

When the skill generates curl / Python / JS code, use these fixed base URLs:

import os

SAPI_BASE = "https://api.binance.com"
MGS_BASE  = "https://www.binance.com"
C2C_WEB   = "https://c2c.binance.com"

def common_headers(api_key: str) -> dict:
    return {
        "X-MBX-APIKEY": api_key,
        "User-Agent": "binance-wallet/1.0.0 (Skill)",
    }

# Usage:
# f"{SAPI_BASE}/sapi/v1/c2c/agent/orderMatch/getUserOrderDetail"
# f"{MGS_BASE}/bapi/c2c/v1/public/c2c/agent/quote-price"
# f"{C2C_WEB}/en/adv?code={advNo}"
# headers = common_headers(os.getenv("BINANCE_API_KEY"))

# Bash equivalent:
SAPI_BASE="https://api.binance.com"
MGS_BASE="https://www.binance.com"
C2C_WEB="https://c2c.binance.com"

Note: SAPI signing uses HMAC SHA256, no param sorting required.

Security & Privacy Rules

Credentials

• Required env vars:
• BINANCE_API_KEY (sent as header)
• BINANCE_SECRET_KEY (used for signing)

Never display full secrets

• API Key: show first 5 + last 4 characters: abc12...z789
• Secret Key: always mask; show only last 5: ***...c123

Permission minimization

• Binance API permissions: Enable Reading only (Phase 1/2).
• Phase 3 ad management additionally needs write permissions.
• Do NOT request/encourage withdrawal or modification permissions beyond what's needed.

Storage guidance

• Prefer environment injection (session/runtime env vars) over writing to disk.
• Only write to .env if the user explicitly agrees.
• Ensure .env is in .gitignore before saving.

⚠️ CRITICAL: SAPI Signing (Different from Standard Binance API)

Parameter ordering

• DO NOT sort parameters for SAPI requests.
• Keep original insertion order when building the query string.

Example:

# ✅ Correct for SAPI: keep insertion order
params = {"page": 1, "rows": 20, "timestamp": 1710460800000}
query_string = urlencode(params)  # NO sorting

# ❌ Wrong (standard Binance API only): sorted
query_string = urlencode(sorted(params.items()))

Signing details

See: references/authentication.md for:

• RFC 3986 percent-encoding
• HMAC SHA256 signing process
• Required headers (incl. User-Agent)
• SAPI-specific parameter ordering

API Overview

Public Queries (MGS C2C Agent API — No Auth)

Base URL: https://www.binance.com

Parameter notes:

• tradeType: BUY or SELL (treat as case-insensitive)
• limit: 1–20 (default 10)
• tradeMethodIdentifiers: pass as a plain string (not JSON array) — e.g. tradeMethodIdentifiers=BANK or tradeMethodIdentifiers=WECHAT. Values must use the identifier field returned by the trade-methods endpoint (see workflow below). ⚠️ Do NOT use JSON array syntax like ["BANK"] — it will return empty results.

Workflow: Compare Prices by Payment Method

When the user wants to compare prices across payment methods (e.g., "Alipay vs WeChat"), follow this two-step flow:

Step 1 — Call trade-methods to get the correct identifiers for the target fiat:

GET /bapi/c2c/v1/public/c2c/agent/trade-methods?fiat=CNY
→ [{"identifier":"ALIPAY",...}, {"identifier":"WECHAT",...}, {"identifier":"BANK",...}]

Step 2 — Pass the identifier as a plain string into ad-list via tradeMethodIdentifiers, one payment method per request, then compare:

GET /bapi/c2c/v1/public/c2c/agent/ad-list?fiat=CNY&asset=USDT&tradeType=BUY&limit=5&tradeMethodIdentifiers=ALIPAY&tradeMethodIdentifiers=WECHAT

Compare the best price from each result set.

Important: Do not hardcode identifier values like "Alipay" or "BANK". Always call trade-methods first to get the exact identifier strings for the given fiat currency.

Personal Orders (Binance SAPI — Requires Auth)

Base URL: https://api.binance.com

Authentication requirements:

• Header: X-MBX-APIKEY
• Query: timestamp + signature
• Header: User-Agent: binance-wallet/1.0.0 (Skill)

Output Format Guidelines

Price quote

• Show both sides when available (best buy / best sell).
• Use fiat symbol and 2-decimal formatting.

Example:

USDT/CNY (P2P)
- Buy USDT (you buy crypto): ¥7.20
- Sell USDT (you sell crypto): ¥7.18

Ad list

Return Top N items with a stable schema: 1) adNo (ad number / identifier) 2) price (fiat) 3) merchant name 4) completion rate 5) limits 6) payment methods (identifiers)

Avoid generating parameterized external URLs unless the API returns them.

Placing orders (when user requests):

• This skill does NOT support automated order placement.
• When user wants to place an order, provide a direct link to the specific ad using the adNo:

  https://c2c.binance.com/en/adv?code={adNo}

• {adNo}: the ad number/identifier from the ad list result

Example: https://c2c.binance.com/en/adv?code=123

• This opens the specific ad detail page where user can place order directly with the selected advertisement.

Personal orders

• Time format: YYYY-MM-DD HH:mm (UTC+0) — always display in UTC timezone
• Include: type, asset/fiat, amount, total, status
• Provide a brief summary line (count + totals) when filtering

Time field conversion (for `createTime` in `listUserOrderHistory`):

• The createTime field returns a Unix timestamp in milliseconds (13 digits).
• Convert to human-readable format in UTC+0 timezone:

  # Python example
  from datetime import datetime, timezone
  readable_time = datetime.fromtimestamp(createTime / 1000, tz=timezone.utc).strftime('%Y-%m-%d %H:%M (UTC+0)')
  
  # JavaScript example
  const readableTime = new Date(createTime).toISOString().replace('T', ' ').slice(0, 16) + ' (UTC+0)';
  // Or more explicitly:
  const date = new Date(createTime);
  const readableTime = date.getUTCFullYear() + '-' +
    String(date.getUTCMonth() + 1).padStart(2, '0') + '-' +
    String(date.getUTCDate()).padStart(2, '0') + ' ' +
    String(date.getUTCHours()).padStart(2, '0') + ':' +
    String(date.getUTCMinutes()).padStart(2, '0') + ' (UTC+0)';

• Always display the converted time to users with timezone info, not the raw timestamp.

Error Handling (User-Facing)

• Invalid API key (-2015): prompt to verify .env / API Management.
• Signature failed (-1022): warn about wrong secret, sorted params, or stale timestamp.
• Timestamp invalid (-1021): advise time sync / regenerate timestamp.
• Rate limit: ask to retry later.

Limitations (By Design)

This skill does NOT:

• Place/cancel orders
• Mark as paid / release coins
• Initiate new appeals / submit-complaint (only evidence supplement for existing appeals is supported)
• Post/modify advertisements (Phase 1/2 only — Phase 3 adds ad management for merchants)
• Expose sensitive order-detail endpoints beyond what's needed for history/summary

For in-app actions, guide users to the official P2P orders page (only as a general entry point).

Developer Notes

Version Check (First Invocation per Conversation)

On the first invocation of this skill per conversation, call:

• GET /bapi/c2c/v1/public/c2c/agent/check-version?version=2.0.0 (Base: https://www.binance.com)

Behavior:

• If needUpdate=true: show: New version of P2P Skill is available (current: {clientVersion}, latest: {latestVersion}), update recommended.
• Else / on failure: proceed silently.

Client-side operations

• Asset filtering: if API doesn't support it, fetch then filter locally.
• Aggregations: compute totals client-side when summary endpoint is insufficient.

---

Phase 3 — Order & Appeal + Ad Publish & Management

Phase 3 extends the skill from read-only market/order queries to write operations (ad management) and advanced order workflows (order detail, appeal/complaint tracking).

Phase 3 Design Constraints

---

Scene 1: Order Query & Appeal Handling

1.1 Query Order Detail

Trigger examples:

• "查看订单 20260315123456 的详情"
• "我最近那笔 USDT 买入订单怎么样了？"
• "帮我查一下这个订单号"
• "Show me the details of order 20260315123456"

Behavior: 1. If user provides an order number → call getUserOrderDetail 2. If user describes an order vaguely → call listOrders with filters, then let user pick 3. Based on order status, branch:

Status branch handling:

Output format (Order Detail):

📋 Order No: {orderNumber}
├─ Type: {tradeType} {asset}
├─ Amount: {amount} {asset} @ {price} {fiatUnit}
├─ Total: {fiatSymbol}{totalPrice}
├─ Status: {orderStatus description}
├─ Counterparty: {buyerNickname / sellerNickname}
├─ Created: {createTime in UTC+0}
│
├─ Timeline:
│  ├─ Created:     {createTime}
│  ├─ Paid:        {notifyPayTime or "—"}
│  ├─ Confirmed:   {confirmPayTime or "—"}
│  └─ Cancelled:   {cancelTime or "—"}
│
├─ Commission: maker {commissionRate}% = {commission} {asset}
│              taker {takerCommissionRate}% = {takerCommission} {asset}
└─ Complaint: {isComplaintAllowed ? "Allowed" : "Not Allowed"} | Status: {complaintStatus or "None"}

Countdown display (for in-progress orders):

• If status=1 (Unpaid): show "Payment deadline: {notifyPayEndTime}" with remaining time
• If status=2 (Paid): show "Release deadline: {confirmPayEndTime}" with remaining time

1.2 View Appeal / Complaint Status

Trigger:

• Automatically when order status = In Appeal (5)
• "这个申诉进展到哪了？"
• "订单 20260315123456 的申诉怎么样了？"
• "What's the appeal status?"

Behavior: 1. Call query-complaints with the order number 2. Display complaint info in structured format

Output format:

⚠️ Appeal Status for Order {orderNo}
├─ Complaint No: {complaintNo}
├─ Status: {complaintStatus description}
├─ Role: {roleIdentity} (COMPLAINANT / RESPONDENT)
├─ Reason: {reason}
├─ Created: {complaintCreateTime}
├─ Order Asset: {orderAsset} | Fiat: {orderFiat}
├─ Order Amount: {orderAmount} ({fiatSymbol})
├─ Amount in USDT: {orderAmountInUsdt}
└─ Dispute Amount: {disputeAmount}

Follow-up guidance (append after the status block, based on complaintStatus):

MUST follow: When complaintStatus is 0, 1, or 2 (appeal still active), NEVER tell the user to "go to the app" or "head to the dispute center". Always guide them to use this skill to submit evidence. The skill supports the full evidence upload flow (Scene 1.5).

Complaint status mapping:

Important: Do NOT confuse these with orderStatus codes — they are separate enums.

When complaintStatus=2 (CS Processing), the user should be guided to submit evidence if needed; do NOT tell them to "wait for counterparty".

1.3 Complaint History Query

Trigger:

• "查看我的所有申诉记录"
• "最近3个月有哪些申诉？"
• "List my complaints as complainant"

Behavior: 1. Call query-complaints with optional filters (roleIdentity, status, date range) 2. Default: last 90 days if no date specified 3. Show paginated results

Output format:

📋 Complaint Records (Total: {total})
┌───────────┬──────────────┬──────────┬────────┬───────────────┐
│ Order No  │ Complaint No │ Status   │ Role   │ Created       │
├───────────┼──────────────┼──────────┼────────┼───────────────┤
│ {orderNo} │ {no}         │ {status} │ {role} │ {time UTC+0}  │
└───────────┴──────────────┴──────────┴────────┴───────────────┘

1.4 Order List & History

Trigger:

• "查看我的订单列表"
• "最近的 USDT 买入订单"
• "Show my completed orders this week"

Behavior:

• For active/recent orders → use listOrders (richer filter: advNo, status, payType)
• For historical orders → use listUserOrderHistory (supports tradeType, date range)

Output format (Order List):

📋 Orders (Page {page}, Total: {total})
┌──────────────┬──────┬───────┬──────────────┬────────┬───────────────┐
│ Order No     │ Type │ Asset │ Total        │ Status │ Created       │
├──────────────┼──────┼───────┼──────────────┼────────┼───────────────┤
│ {orderNo}    │ BUY  │ USDT  │ ¥{totalPrice}│ 已完成  │ {time UTC+0}  │
└──────────────┴──────┴───────┴──────────────┴────────┴───────────────┘

Order status code mapping:

1.5 Submit Appeal Evidence

Trigger:

• "帮我上传这个截图作为申诉证据"
• "我要提交付款凭证"
• "Submit evidence for order 228..."
• "Upload proof of payment for my appeal"
• Automatically suggested when order is in Appeal (status=5) and complaintStatus=2 (CS Processing)

Behavior (3-step flow):

Step 1 — Get presigned upload URL:

GET /sapi/v1/c2c/agent/file-upload/get-s3-presigned-url?fileName=proof.jpg&scenario=complaint
→ { "uploadUrl": "https://s3...presigned...", "filePath": "/client_upload/c2c/complaint/..." }

Step 2 — Upload file to S3:

curl -X PUT -T /path/to/local/file.jpg "{uploadUrl}"

The presigned URL is valid for 5 minutes. Upload must complete within this window.

Step 3 — Submit evidence to SAPI:

POST /sapi/v1/c2c/agent/complaint/submit-evidence
Body: { "orderNo": "228...", "description": "付款截图", "fileUrls": ["/client_upload/c2c/complaint/..."] }
→ { "data": true }

Supported file types: txt, doc, xls, docx, xlsx, jpg, jpeg, png, pdf, mp3, mp4, avi, rm, rmvb, mov, wmv

Output format (Upload Progress):

📤 Evidence Upload for Order {orderNo}
├─ Step 1/3: Getting upload URL... ✅
├─ Step 2/3: Uploading file "{fileName}"... ✅
├─ Step 3/3: Submitting evidence...
│  ├─ Description: {description}
│  └─ Files: {n} file(s)
└─ Result: ✅ Evidence submitted successfully

💡 Tip: You can submit additional evidence by saying "再上传一个文件"

Output format (Failure):

❌ Evidence Upload Failed
├─ Step: {which step failed}
├─ Error: {error message}
└─ Suggestion: {actionable fix}

Common errors:

• Unsupported file type → Check file extension; see supported types above
• Presigned URL expired → Re-request upload URL (Step 1)
• Order not in appeal → Evidence can only be submitted for orders with active complaints
• File too large → Reduce file size or split into multiple files

Write-op confirmation rule: Evidence submission follows the same confirmation protocol as Scene 2 write operations: 1. Show a summary of what will be submitted (file name, description, order number) 2. Wait for user to confirm before executing Step 3

Confirmation format:

📋 Evidence Submission Summary
├─ Order: {orderNo}
├─ Description: {description}
├─ Files to submit:
│  1. {fileName1} ({fileType}, uploaded ✅)
│  2. {fileName2} ({fileType}, uploaded ✅)
└─ ⚠️ Confirm submission? (reply "确认" or "confirm")

1.6 View Complaint Process Timeline

Trigger:

• "查看申诉的处理流程"
• "这个申诉经历了哪些步骤？"
• "Show complaint timeline for order 228..."
• "What happened in the appeal process?"

Behavior: 1. Call get-complaint-flows with orderNo (and optionally complaintNo) 2. Display chronological timeline of all process steps

Output format:

📜 Complaint Timeline: Order {orderNo} (Complaint #{complaintNo})
│
├─ [{createTime}] {creatorNickName}
│  ├─ Type: {infoType description}
│  ├─ Description: {description}
│  ├─ Evidence: {fileUrls count} file(s) attached
│  └─ Source: {source}
│
├─ [{createTime}] {operatorName or creatorNickName}
│  ├─ Type: {infoType description}
│  ├─ Remark: {remark}
│  └─ Evidence: {fileUrls or "None"}
│
└─ ... (chronological order)

💡 Actions: "提交证据" to submit evidence | "刷新" to check for updates

Info type mapping (for display):

Note: fileUrls in the response are CDN-assembled URLs that can be directly accessed.

remarkHtml takes precedence over remark when available for rendering.

1.7 Cancel Complaint / Appeal

Trigger:

• "取消这个申诉"
• "我不想继续申诉了"
• "Cancel my appeal for order 228..."
• "Withdraw my complaint"

⚠️ This is a DESTRUCTIVE action — mandatory confirmation required!

Cancelling an appeal is irreversible. The user forfeits their dispute and the order proceeds to its normal resolution. The agent MUST follow this strict confirmation protocol:

Behavior: 1. When user expresses intent to cancel, FIRST show a clear warning 2. Wait for explicit confirmation ("确认取消" / "confirm cancel" / "yes") 3. Only then call cancel-complaint with the orderNo 4. Display the result

Warning format (MUST show before executing):

⚠️ Cancel Appeal Confirmation
├─ Order: {orderNo}
├─ Current complaint status: {status from previous query if available}
│
╔══════════════════════════════════════════════╗
║  WARNING: This action CANNOT be undone!      ║
║  - Your appeal will be permanently withdrawn ║
║  - You will lose the right to dispute this   ║
║    order through the appeal process          ║
║  - The order will proceed to normal          ║
║    resolution without CS intervention        ║
╚══════════════════════════════════════════════╝
│
└─ Reply "确认取消" or "confirm cancel" to proceed

On success:

✅ Appeal Cancelled
├─ Order: {orderNo}
├─ Status: Appeal withdrawn
└─ The order will now proceed to normal resolution.

On failure:

❌ Cancel Failed
├─ Order: {orderNo}
├─ Reason: {error message}
└─ Possible causes: no active appeal, order already resolved, or insufficient permissions.

MUST-follow rules:

• NEVER cancel without showing the warning and receiving explicit confirmation
• If user says anything ambiguous (like "算了" / "never mind" in a conversation about something else), do NOT interpret it as cancel intent — ask to clarify
• If the complaint status is already resolved/closed, inform user instead of attempting the API call

1.8 Get Complaint Reasons

Trigger:

• "我可以用什么理由申诉？"
• "What reasons can I use to appeal?"
• "Show available complaint reasons for this order"
• "申诉理由有哪些？"

Behavior: 1. Call get-complaint-reasons with orderNo 2. Display the list of available reason codes and descriptions

Output format:

📋 Available Complaint Reasons for Order {orderNo}
│
├─ [{reasonCode}] {reasonDesc}
├─ [{reasonCode}] {reasonDesc}
├─ [{reasonCode}] {reasonDesc}
└─ ...

💡 Note: These are the reasons you can use when initiating an appeal.
   This skill does NOT support initiating appeals — only viewing reasons.

Note: This is a read-only informational query. The skill does NOT support actually submitting a new complaint (that requires the user to use the App).

---

Scene 2: Ad Publish & Management

⚠️ Write Operation Safety Rules

ALL write operations in Scene 2 MUST follow this protocol:

1. Pre-check: Verify user has merchant permission (the API itself checks, but inform user clearly on 403/Permission denied) 2. Show summary: Before executing any write API, display a complete operation summary 3. Explicit confirmation: Wait for user to say "确认" / "confirm" / "发布" / "yes" before proceeding 4. Never auto-execute: Even if user says "just do it" in the initial request, still show summary first

2.1 Market Analysis & Reference Pricing

Trigger:

• "我想发一个 USDT/CNY 的卖单广告"
• "帮我挂一个 BTC 买单"
• "当前市场参考价是多少？"
• "What's the reference price for USDT/CNY?"

Behavior: 1. Call getReferencePrice to get market reference prices 2. Call search to analyze current market ad distribution 3. Present pricing intelligence to help user decide

Output format (Reference Price):

📊 Market Reference Price
├─ Asset: {asset} / {fiatCurrency}
├─ Reference Price: {currencySymbol}{referencePrice}
├─ Price Scale: {priceScale} decimals
└─ Asset Scale: {assetScale} decimals

Output format (Market Analysis):

📊 Market Ad Analysis: {asset}/{fiat} ({tradeType})
├─ Total Active Ads: {total}
├─ Price Range: {min} ~ {max}
├─ Top 5 Ads:
│  1. {advNo} | {price} | {surplusAmount} {asset} | Limit: {min}~{max} | {merchantNick}
│     └─ Terms: {remarks or "—"}
│  2. ...
└─ Recommended Price: {suggestion based on reference + market}

2.2 Ad Configuration

Trigger:

• "用浮动价格，溢价 0.5%"
• "加上支付宝"
• "就按推荐的来"
• "单价改成 6.99，限额改到 1000-100000"

Pre-publish preparation workflow:

Step 1 — Get available categories:

GET /sapi/v1/c2c/agent/ads/getAvailableAdsCategory
→ {"advClassifies": ["mass", "profession", ...]}

Step 2 — Get user's payment methods (for SELL ads, need payId):

GET /sapi/v1/c2c/agent/ads/getPayMethodByUserId
→ [{"payId": 123, "identifier": "ALIPAY", "tradeMethodName": "支付宝"}]

Display rule: Only show tradeMethodName (e.g. "支付宝", "WeChat", "Bank Transfer") to the user.

payId is an internal identifier used only in the API request body — never expose payId values in user-facing output.

Step 3 — Get all system trade methods (for BUY ads, need identifier):

POST /sapi/v1/c2c/agent/ads/listAllTradeMethods
→ [{"identifier": "ALIPAY", "tradeMethodName": "支付宝", ...}]

Ad parameter reference:

Confirmation summary format:

📋 Ad Configuration Summary
┌────────────────────────────────────┐
│ Trade Direction: {SELL/BUY} {asset}│
│ Fiat Currency:   {fiatUnit}        │
│ Price Type:      {Fixed/Floating}  │
│ Price:           {price or ratio%} │
│ Total Quantity:  {initAmount} {asset}│
│ Order Limit:     {min} ~ {max} {fiat}│
│ Payment Methods: {method1, method2}│
│ Payment Timeout: {payTimeLimit} min│
│ Status:          {Online/Offline}  │
├────────────────────────────────────┤
│ Advanced Settings:                 │
│  Buyer KYC: {Yes/No}              │
│  Min Reg Days: {days or "—"}      │
│  Min BTC: {amount or "—"}         │
│  Extra Verify: {Yes/No}           │
│  Regions: {countries or "All"}    │
│  Remarks: {text or "—"}           │
│  Auto Reply: {text or "—"}        │
└────────────────────────────────────┘

⚠️ Please confirm to publish (reply "确认" or "confirm")

2.3 Publish Ad

Trigger:

• "确认" / "confirm" / "发布" (after 2.2 summary)

Behavior: 1. User confirms → call POST /sapi/v1/c2c/agent/ads/post 2. Return result

Output format (Success):

✅ Ad Published Successfully!
├─ Ad Number: {advNo}
├─ Status: Online
├─ View: https://c2c.binance.com/en/adv?code={advNo}
└─ Manage: say "查看我的广告" to see all your ads

Output format (Failure):

❌ Ad Publish Failed
├─ Error: {error message}
└─ Suggestion: {actionable fix}

Common errors:

• Permission denied → User is not a verified merchant
• FIAT_ASSET_ILLEGAL → BIDR can only pair with IDR
• Insufficient balance → Check asset balance before publishing

2.4 Manage Existing Ads

Trigger:

• "查看我的广告" / "List my ads"
• "把第 1 条广告下架" / "Take the first ad offline"
• "修改我那条 USDT 卖单的价格" / "Update price for my USDT sell ad"

List My Ads

Call POST /sapi/v1/c2c/agent/ads/listWithPagination

Output format:

📋 My Advertisements (Total: {total})
┌────┬──────────────┬──────┬───────┬──────────┬─────────────┬──────────┬────────┐
│ #  │ Ad No        │ Type │ Asset │ Price    │ Remaining   │ Limit    │ Status │
├────┼──────────────┼──────┼───────┼──────────┼─────────────┼──────────┼────────┤
│ 1  │ {advNo}      │ SELL │ USDT  │ ¥{price} │ {surplus}   │ {min}~{max}│ Online │
│ 2  │ {advNo}      │ BUY  │ BTC   │ ¥{price} │ {surplus}   │ {min}~{max}│ Offline│
└────┴──────────────┴──────┴───────┴──────────┴─────────────┴──────────┴────────┘

# If any ad has remarks or autoReplyMsg, show below the table:
Ad Terms:
  #1: {remarks or "—"} | Auto-reply: {autoReplyMsg or "—"}
  #2: {remarks or "—"} | Auto-reply: {autoReplyMsg or "—"}

Actions: "修改第1条广告价格" | "下架第2条" | "查看详情 {advNo}"

View Ad Detail

Call POST /sapi/v1/c2c/agent/ads/getDetailByNo

Trigger: "查看详情 {advNo}" / "Show ad detail"

Output format:

📄 Ad Detail: {advNo}
├─ Type: {tradeType} {asset}/{fiatUnit}
├─ Price: {currencySymbol}{price} ({priceType: Fixed/Floating})
├─ Remaining: {surplusAmount} / {initAmount} {asset}
├─ Limit: {minSingleTransAmount} ~ {maxSingleTransAmount} {fiatUnit}
├─ Payment Methods: {tradeMethodName1, tradeMethodName2}
├─ Status: {status}
├─ Payment Timeout: {payTimeLimit} min
│
├─ Trading Terms:
│  {remarks or "No terms set"}
│
├─ Auto-Reply Message:
│  {autoReplyMsg or "No auto-reply set"}
│
└─ Advanced:
   ├─ Buyer KYC: {Yes/No}
   ├─ Min Reg Days: {buyerRegDaysLimit or "—"}
   └─ Extra Verify: {takerAdditionalKycRequired ? "Yes" : "No"}

Display rule for `remarks` and `autoReplyMsg`: These fields are returned by getDetailByNo, listWithPagination, and search. When present and non-empty, always show them. When null/empty, show "—" or a placeholder like "No terms set". Never omit the section silently — the user should know whether terms exist.

Ad status code mapping:

Update Ad

Behavior: 1. Identify which ad to update (by # in list or advNo) 2. Show diff: old value → new value 3. Wait for confirmation 4. Call POST /sapi/v1/c2c/agent/ads/update

Confirmation format:

📝 Update Ad: {advNo}
┌──────────────┬─────────────┬─────────────┐
│ Field        │ Current     │ New         │
├──────────────┼─────────────┼─────────────┤
│ Price        │ ¥7.20       │ ¥6.99       │
│ Max Limit    │ ¥50,000     │ ¥100,000    │
└──────────────┴─────────────┴─────────────┘

⚠️ Confirm update? (reply "确认" or "confirm")

Update Ad Status (Online / Offline / Close)

Behavior: 1. Identify target ad(s) — supports batch operation 2. Show confirmation 3. Call POST /sapi/v1/c2c/agent/ads/updateStatus

Confirmation format:

🔄 Status Update
├─ Ads: {advNo1}, {advNo2}
├─ Action: {Online → Offline}
└─ ⚠️ Confirm? (reply "确认" or "confirm")

Result format:

✅ Status updated: {n} ad(s) → {status}
# Or if partial failure:
⚠️ Partial success: {n} updated, {m} failed
Failed:
├─ {advNo}: {errorMessage}

---

Scene 2 Supplement: Merchant & Currency Queries

View Merchant Profile

Trigger:

• "查看商家 {merchantNo} 的信息"
• "Show me merchant details"

Behavior: Call GET /sapi/v1/c2c/agent/merchant/getAdDetails?merchantNo={merchantNo}

Output format:

👤 Merchant: {nickName}
├─ Type: {userType}
├─ Total Orders: {orderCount}
├─ 30-Day Orders: {monthOrderCount}
├─ 30-Day Completion: {monthFinishRate}%
├─ Avg Release Time: {advConfirmTime}s
├─ Online: {onlineStatus}
├─ Registered: {registerDays} days
│
├─ 30-Day Stats:
│  ├─ Avg Release: {avgReleaseTimeOfLatest30day}s
│  ├─ Avg Payment: {avgPayTimeOfLatest30day}s
│  └─ Completed: {completedOrderNumOfLatest30day}
│
├─ Buy Ads ({n}):
│  1. {advNo} | {asset}/{fiat} | {price} | {surplus} remaining
│     └─ Terms: {remarks or "—"}
│
└─ Sell Ads ({n}):
   1. {advNo} | {asset}/{fiat} | {price} | {surplus} remaining
      └─ Terms: {remarks or "—"}

List Supported Currencies

Trigger:

• "P2P支持哪些币种？"
• "What fiat currencies are supported?"

Behavior:

• Digital currencies: POST /sapi/v1/c2c/agent/digitalCurrency/list
• Fiat currencies: POST /sapi/v1/c2c/agent/fiatCurrency/list

---

Phase 3 API Overview

Order & Appeal (SAPI Agent — Requires Auth)

Base URL: https://api.binance.com

Ad Management (SAPI Agent — Requires Auth)

Base URL: https://api.binance.com

Merchant (SAPI Agent — Requires Auth)

Base URL: https://api.binance.com

Support (SAPI Agent — Requires Auth)

Base URL: https://api.binance.com

Full API reference with request/response schemas: see references/agent-sapi-api.md

Phase 3 Error Handling (Additional)

Phase 3 Limitations

This skill does NOT (in Phase 3):

• Initiate new appeals / submit-complaint (only evidence supplement for existing appeals is supported)
• Auto-monitor appeal status changes (polling not supported in skill)
• Place orders on behalf of user (guide to ad detail page instead)
• Access chat messages or send messages in order chat
• Modify payment method configurations (only read)
• Access KYC/verification status details

For appeal initiation and real-time appeal monitoring, guide users to the official P2P dispute center.

Changelog

1.1.0 - 2026-04-20

Scene 1: Order Query & Appeal Handling

• Added: Order detail query by order number (getUserOrderDetail)
• Added: Order list with rich filters — status, trade type, asset, date range (listOrders)
• Added: Enhanced order history with counterpart nickname and advertisement role (listUserOrderHistory)
• Added: Complaint/appeal status query with pagination and filters (query-complaints)
• Added: Order status branch handling (completed → timeline, in-progress → countdown, appealing → auto-show appeal)

Scene 2: Ad Publish & Management (Merchant Only)

• Added: Market reference price query for pricing decisions (getReferencePrice)
• Added: Market ad search with advertiser info (search)
• Added: Get available ad categories for current user (getAvailableAdsCategory)
• Added: Get user's configured payment methods (getPayMethodByUserId)
• Added: List all system trade methods (listAllTradeMethods)
• Added: Publish new advertisements with confirmation flow (post) [write operation]
• Added: Update existing ad parameters with diff display (update) [write operation]
• Added: Batch update ad status — online/offline/close (updateStatus) [write operation]

Merchant & Support

• Added: Merchant profile and ad listings query (getAdDetails)
• Added: List supported digital currencies (digitalCurrency/list)
• Added: List supported fiat currencies (fiatCurrency/list)

1.0.1 - 2026-03-25

• Changed: Update order placement link format from filtered list page to ad-specific detail page using adNo parameter (https://c2c.binance.com/en/adv?code={adNo})

1.0.0 - 2026-03-24

• Initial release

MIT License

Copyright (c) 2026 Binance

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Agent SAPI API Reference

Complete API reference for all C2C Agent SAPI endpoints used by the P2P Skill (Phase 3).

All endpoints require authentication (API Key + HMAC SHA256 signature). See authentication.md for signing details.

Base URL: https://api.binance.com

Common Headers:

X-MBX-APIKEY: {your_api_key}
User-Agent: binance-wallet/1.0.0 (Skill)

Common Response Wrapper:

{
  "code": "000000",
  "message": null,
  "data": { ... },
  "success": true
}

Paginated Response Wrapper:

{
  "code": "000000",
  "data": [ ... ],
  "total": 100,
  "success": true
}

---

1. Order Match APIs

1.1 Get Order Detail

Get detailed information for a specific order.

POST /sapi/v1/c2c/agent/orderMatch/getUserOrderDetail

Request Body (JSON):

Response (AgentOrderDetailResp):

Example:

curl -X POST "https://api.binance.com/sapi/v1/c2c/agent/orderMatch/getUserOrderDetail?timestamp=${TIMESTAMP}&signature=${SIGNATURE}" \
  -H "X-MBX-APIKEY: ${API_KEY}" \
  -H "User-Agent: binance-wallet/1.0.0 (Skill)" \
  -H "Content-Type: application/json" \
  -d '{"orderNumber": "20260315123456789"}'

Note: See authentication.md for the complete Bash signing setup.

---

1.2 List Orders

List orders with rich filters and pagination.

POST /sapi/v1/c2c/agent/orderMatch/listOrders

Request Body (JSON):

Response (Paginated List of AgentOrderListResp):

---

1.3 List User Order History

List historical orders with pagination.

GET /sapi/v1/c2c/agent/orderMatch/listUserOrderHistory

Query Parameters:

Response (Paginated List of AgentOrderHistoryResp):

---

2. Complaint APIs

2.1 Query Complaints

Query complaint/appeal records with filters and pagination.

POST /sapi/v1/c2c/agent/complaint/query-complaints

Request Body (JSON):

Response (Paginated List of AgentComplaintQueryResp):

---

3. Ads APIs

3.1 Get Ad Detail By Number

POST /sapi/v1/c2c/agent/ads/getDetailByNo?advNo={advNo}

Query Parameters:

Note: This endpoint only returns ads owned by the authenticated user. Querying another user's ad will return error -1002.

Response (AgentAdDetailResp):

AgentTradeMethodResp:

---

3.2 List Ads With Pagination

List current user's own advertisements.

POST /sapi/v1/c2c/agent/ads/listWithPagination

Request Body (JSON):

Response: Paginated list of AgentAdDetailResp (same schema as 3.1).

---

3.3 Search Ads

Search market ads with rich filters.

POST /sapi/v1/c2c/agent/ads/search

Request Body (JSON):

Response (Paginated List of AgentAdSearchResp):

AgentAdvertiserResp:

---

3.4 Get Reference Price

Get market reference prices for pricing decisions.

POST /sapi/v1/c2c/agent/ads/getReferencePrice

Request Body (JSON):

Response (List of AgentAdReferencePriceResp):

---

3.5 Get Available Ads Category

Get ad categories the current user can publish.

GET /sapi/v1/c2c/agent/ads/getAvailableAdsCategory

No request body.

Response (AgentAdsCategoryResp):

---

3.6 Get User Payment Methods

Get current user's configured payment methods (agent-safe: no account details).

GET /sapi/v1/c2c/agent/ads/getPayMethodByUserId

No request body.

Response (List of AgentPayMethodResp):

Note: For SELL ads, use payId in tradeMethods. For BUY ads, use identifier from system trade methods.

---

3.7 List All System Trade Methods

List all available trade methods in the system.

POST /sapi/v1/c2c/agent/ads/listAllTradeMethods

No request body.

Response (List of TradeMethodBaseInfoVO):

---

3.8 Post Ad (Write Operation)

Publish a new advertisement. Requires merchant permission.

POST /sapi/v1/c2c/agent/ads/post

Request Body (JSON):

TradeMethod object:

Response: CommonRet<String> where data is the new ad number (advNo).

---

3.9 Update Ad (Write Operation)

Update an existing advertisement. Requires merchant permission.

Important — full-object update: The downstream service validates the complete ad object, not just the changed fields. Sending only advNo + one field (e.g. price) will result in error -9000. The recommended workflow is:

1. Call getDetailByNo?advNo={advNo} to fetch the current ad.

2. Merge your changes into the full response object.

3. Submit the merged object to this endpoint.

POST /sapi/v1/c2c/agent/ads/update

Request Body (JSON):

Response: CommonRet<Boolean> — true if update succeeded.

---

3.10 Update Ad Status (Write Operation)

Batch update advertisement status (online/offline/close).

POST /sapi/v1/c2c/agent/ads/updateStatus

Request Body (JSON):

Response (AgentAdUpdateStatusResp):

StatusUpdateResult:

---

4. Merchant APIs

4.1 Get Merchant Ad Details

Get merchant public profile with buy/sell ad listings.

GET /sapi/v1/c2c/agent/merchant/getAdDetails?merchantNo={merchantNo}

Query Parameters:

Response (AgentMerchantAdsDetailResp):

AgentMerchantDetailResp:

---

5. Support APIs

5.1 List Digital Currencies

POST /sapi/v1/c2c/agent/digitalCurrency/list

No request body.

Response: List<DigitalCurrencyResponse> — all supported digital currencies.

---

5.2 List Fiat Currencies

POST /sapi/v1/c2c/agent/fiatCurrency/list

No request body.

Response: List<FiatCurrencyResponse> — all supported fiat currencies.

---

Authentication Notes

All Agent SAPI endpoints share the same authentication mechanism:

1. All requests require timestamp and signature query parameters 2. SAPI signing: DO NOT sort parameters — keep insertion order 3. Required headers: X-MBX-APIKEY + User-Agent 4. See authentication.md for complete signing process

Privacy & Security

All Agent SAPI responses are pre-filtered at the DTO level:

• Excluded: real names, phone numbers, emails, bank accounts, payment details, KYC info
• Included: nicknames (not masked), order/ad data, trade statistics
• The Agent field filter (AgentFieldFilter) handles any runtime masking needed

6. File Upload (AgentFileUploadController)

Base path: /sapi/v1/c2c/agent/file-upload

6.1 Get S3 Presigned URL

GET /sapi/v1/c2c/agent/file-upload/get-s3-presigned-url

Get a presigned S3 URL for uploading complaint evidence files. The URL is valid for 5 minutes.

Query Parameters:

Response: S3FileUrlInfo

Supported file types (complaint scenario): txt, doc, xls, docx, xlsx, jpg, jpeg, png, pdf, mp3, mp4, avi, rm, rmvb, mov, wmv

Upload flow: 1. Call this endpoint to get uploadUrl and filePath 2. PUT the file binary to uploadUrl (must complete within 5 minutes) 3. Use filePath in the submit-evidence request

---

7. Complaint Operations (AgentComplaintController — Extended)

These endpoints extend the existing complaint controller (Section 2).

7.1 Submit Appeal Evidence

POST /sapi/v1/c2c/agent/complaint/submit-evidence

Submit supplementary evidence for an existing complaint/appeal.

Request Body: AgentComplaintSupplementReq

Response: Boolean — true if evidence submitted successfully.

Error cases:

• Order not found / not in appeal → error response
• No active complaint for order → error response
• File URLs not from valid S3 upload → may fail validation

---

7.2 Get Complaint Flows (Timeline)

POST /sapi/v1/c2c/agent/complaint/get-complaint-flows

Get the chronological timeline of a complaint process, including all actions, evidence submissions, and CS reviews.

Request Body: AgentComplaintFlowQueryReq

Response: List<AgentComplaintFlowResp>

---

7.3 Cancel Complaint

POST /sapi/v1/c2c/agent/complaint/cancel-complaint

Cancel (withdraw) an existing complaint/appeal for an order. This is an irreversible action.

Request Body: AgentComplaintCancelReq

Response: Boolean — true if the complaint was successfully cancelled.

Error cases:

• Order not found → error response
• No active complaint for order → error response
• Complaint already resolved/closed → error response
• User not the complaint initiator → error response

Important: The agent MUST confirm with the user before calling this endpoint, as cancelling an appeal is irreversible and the user forfeits their dispute rights.

---

7.4 Get Complaint Reasons

POST /sapi/v1/c2c/agent/complaint/get-complaint-reasons

Get available complaint/appeal reasons for a given order. Returns localized reason descriptions.

Request Body: AgentComplaintCancelReq (reused — only needs orderNo)

Response: List<AgentComplaintReasonResp>

Error cases:

• Order not found → error response
• Order not in a state where complaints are applicable → error response

Binance P2P Authentication

All P2P personal order endpoints (SAPI) require HMAC SHA256 signed requests.

Base URL

https://api.binance.com

Required Headers

• X-MBX-APIKEY: your_api_key
• User-Agent: binance-wallet/1.0.0 (Skill)

⚠️ CRITICAL: SAPI-Specific Behavior

DO NOT sort parameters - SAPI keeps original insertion order (different from standard Binance API).

Correct approach for SAPI:

• Keep parameter insertion order when building query string
• Example: page=1&rows=20&recvWindow=60000&timestamp=1710460800000

Wrong approach (standard Binance API only):

• Sorting parameters alphabetically will cause signature verification failure
• SAPI does NOT sort parameters like standard REST API

Signing Process

Step 1: Build Query String

Include all parameters plus timestamp (current Unix time in milliseconds): timestamp=1234567890123

Optional: Add recvWindow (default 60000ms for P2P endpoints) for timestamp tolerance.

Step 2: Percent-Encode Parameters

Before generating the signature, percent-encode all parameter names and values using UTF-8 encoding according to RFC 3986. Unreserved characters that must not be encoded: A-Z a-z 0-9 - _ . ~

• Chinese characters example:

symbol=这是测试币456

Percent-encoded: symbol=%E8%BF%99%E6%98%AF%E6%B5%8B%E8%AF%95%E5%B8%81456

Important: The exact encoded query string must be used for both signing and the HTTP request.

Step 3: Generate Signature

Generate the HMAC SHA256 signature from the encoded query string using your secret key:

# Example using openssl
echo -n "page=1&rows=20&recvWindow=60000&timestamp=1234567890123" | \
  openssl dgst -sha256 -hmac "your_secret_key"

Step 4: Append Signature

Add signature parameter to the query string: page=1&rows=20&recvWindow=60000&timestamp=1234567890123&signature=abc123...

Step 5: Add Headers

Include required headers:

• X-MBX-APIKEY: Your API key
• User-Agent: binance-wallet/1.0.0 (Skill)

Complete Bash Example

#!/bin/bash
API_KEY="your_api_key"
SECRET_KEY="your_secret_key"
BASE_URL="https://api.binance.com"

# Get current timestamp
TIMESTAMP=$(date +%s000)

# Build query string (without signature)
# CRITICAL: Keep parameter order, do NOT sort
QUERY="page=1&rows=20&recvWindow=60000&timestamp=${TIMESTAMP}"

# Generate signature
SIGNATURE=$(echo -n "$QUERY" | openssl dgst -sha256 -hmac "$SECRET_KEY" | cut -d' ' -f2)

# Make request
curl -X GET \
  "${BASE_URL}/sapi/v1/c2c/orderMatch/listUserOrderHistory?${QUERY}&signature=${SIGNATURE}" \
  -H "X-MBX-APIKEY: ${API_KEY}" \
  -H "User-Agent: binance-wallet/1.0.0 (Skill)"

Security Notes

• Never share your secret key
• Use IP whitelist in Binance API settings
• Enable only required permissions (Enable Reading for P2P order history)
• Store credentials securely in .env file (add to .gitignore)