Find the report.
Let your AI work with the data.

Read GET /api/agents/reports?slug=cotton. Continue only when usdc_purchase_api.available is true. The existing purchase_api and USD price fields describe cards; each offer’s usdc fields describe the separate Base price. For example, 79000000 atomic units is 79 USDC.

Use an approved EOA wallet; contract wallets are not supported. Your agent’s per-payment budget must cover the selected 79 or 199 USDC offer. Do not silently raise its budget. The protocol is x402 v2, exact, on Base eip155:8453. This site uses the explicit quote/challenge/submission steps below.

1. Create one authorized quote

Present the report, dates, scope, USDC price and terms to the buyer. Obtain their authorization, licence business name and delivery email. Generate a cryptographically random 32-byte lowercase hex purchase key in a secret store. It is separate from the wallet’s private key. Retain the same key and request body for all retries of this purchase.

POST https://tradescopeasia.com/api/agents/usdc/purchases
Authorization: Bearer <private-purchase-key>
Content-Type: application/json

{"slug":"cotton","tier":"snapshot","business_name":"Example Trading","email":"buyer@example.com","buyer_authorized":true,"terms_accepted":true}

Supply exactly these six fields. Use snapshot or historical. The business name must be 2–120 printable Latin/ASCII characters; use a recognized Latin spelling for a non-Latin name. Use the buyer’s actual delivery email. Creating the quote moves no funds.

2. Review the payment challenge

The create response returns id, offer and status_url. GET that status URL with the same Bearer key. HTTP 402 returns the x402 challenge in the JSON body and PAYMENT-REQUIRED header. Validate the exact amount, native USDC token, Base network, recipient, resource URL and accepted terms against the offer. The server returns HTTP 410 when the unpaid quote expires; the challenge’s maxTimeoutSeconds limits authorization duration and is not an absolute quote deadline. An expired or paused quote is not permission to send funds.

3. Authorize one payment and submit

Use the compatible wallet’s x402 signing flow to authorize that exact transfer. Signing grants permission for the payment service to transfer the stated USDC amount. Save the resulting authorization privately before submitting it.

POST <the same status_url>
Authorization: Bearer <the same private-purchase-key>
PAYMENT-SIGNATURE: <encoded x402 payment payload>

(empty request body)

4. Check the original purchase

GET the same status_url with the same key, no more than once every five seconds, and honor Retry-After. HTTP 202 means verification is pending. On a timeout, rate limit or HTTP 503, retain this purchase and any saved authorization; do not create a new key or sign another payment to work around the interruption.

If submission failed before the service retained the authorization, a fresh GET may still return HTTP 402. Validate that challenge against the original purchase and the saved payload. If they match, you may resubmit the identical saved PAYMENT-SIGNATURE to the original status URL with the same key and an empty body, respecting Retry-After. Do not generate a replacement authorization. If the saved authorization has expired or the details differ, stop and contact support.

HTTP 200 with status: "ready" returns receipt.delivery.url. Download the ZIP once and save it privately. Read its licence and coverage before analysis. Refunded, revoked, expired or exhausted access is not a new purchase instruction. For HTTP 400/401/403/404/409/410, inspect the response and seek assistance as needed.

Keep purchase keys, signed authorizations, buyer details and private download links out of URLs, public search queries and logs. Catalogue availability reflects configuration; it does not guarantee a provider is reachable. The purchase response is authoritative. Preview disables real purchases.