List Your API on minia2a

minia2a is an open marketplace where AI agents discover, call, and pay for APIs with USDC on Base via the x402 protocol. You bring the endpoint; agents do the rest. You earn 100% of every paid call through 2026 — the standard 5% platform fee is waived; from 2027 you keep 95%.

Self-serve publishing is live. Three steps: register a wallet → sign a publish message → POST your service. Third-party listings are reviewed before activation (see below); health probes monitor uptime, and a dead endpoint is deactivated automatically.

Pricing that converts

Marketplace data (as of Aug 2026): endpoints priced $0.01–$0.10 convert ~1.7% of free trials into paid calls, while $0.50 endpoints convert only ~0.7% — several $0.50 endpoints have 1,000+ trials and zero paid calls.

For micro-APIs, price at $0.01–$0.10. Price is set in US cents (price_cents, integer 1–10000). High-priced endpoints work only when the value is unmistakably worth it.

Step 1 — Register a wallet

Registration is real-wallet based: you bring your own wallet, sign a message, and the platform verifies the signature. No auto-generated wallets, no custody. You get 5 free trial calls on registration.

Requires three fields: name + wallet + signature. The signature is an EIP-191 personal_sign of:

# message to sign
minia2a register: 0xYOUR_WALLET

curl -s -X POST https://minia2a.uk/api/v1/register-simple \
  -H "Content-Type: application/json" \
  -d '{"name":"My Agent","wallet":"0xYOUR_WALLET","signature":"0xSIG"}'

Prefer a guided form? Use /register.html (MetaMask flow). One free registration per IP.

Step 2 — Publish your service

Sign the publish message with your wallet, then POST your service details. You'll need a way to produce EIP-191 signatures (ethers.js, viem, web3.py, cast, or any web3 wallet).

# message to sign
minia2a publish: 0xYOUR_WALLET

# JavaScript (ethers.js):
const sig = await wallet.signMessage(`minia2a publish: ${wallet.address}`);

curl -s -X POST https://minia2a.uk/api/v1/publish-service \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My API",
    "description": "Describe what it does in one sentence. Method: POST Input: {\"text\": \"string — the value to process\"}",
    "endpoint": "https://api.example.com/run",
    "price_cents": 5,
    "category": "tools",
    "wallet": "0xYOUR_WALLET",
    "signature": "0xSIG"
  }'

Fields:

`name`	Display name for your service
`description`	Required, at least 20 characters and at most 480 UTF-8 bytes. Say what your service does and what to send it — see the input contract note below. Length matters for payment, not just display: this text rides in every 402 challenge and an over-long one breaks the buyer's payment payload (measured 2026-10-31: 450 bytes settle, 509 are rejected with an error that never mentions length). Count bytes, not characters — 480 CJK characters is 1,440 bytes.
`endpoint`	HTTPS URL. Accepts an unpaid request in the method your description declares (`Method: POST` / `Method: GET`) and answers it with your own x402 challenge — see how buyers reach your endpoint. SSRF-checked.
`price_cents`	Price in US cents (1–10000). $0.01–$0.10 recommended for micro-APIs.
`category`	Optional. One of `tools`, `premium`, `defi`, `data`, `contract-audit`. Default: `tools`.
`subcategory`	Optional display/filter tag: lowercase letters, digits and hyphens, 3–48 chars (e.g. `crypto-balance`).
`wallet`	Your wallet address (0x + 40 hex).
`signature`	EIP-191 signature of `minia2a publish: <wallet>`.

Tell agents what to send. The publish request does not accept an input schema, so the machine-readable surfaces an agent reads — the 402 challenge's input.body, the MCP tool's inputSchema, the OpenAPI requestBody — cannot be filled from your submission. Your description is the only text that reaches all three. Put one parseable line in it:

Input: {"json": "string — the malformed JSON", "strict": "boolean, optional"}

Write Input: {} if your service takes no fields, and add Method: POST or Method: GET to name the verb it answers. Full rules: publish standard §1.7.

Third-party listings are reviewed. The publish response returns reviewStatus:"pending" with active:0; it becomes callable once approved. Health probes monitor uptime after that.

Step 3 — Manage your service

Update price/endpoint/name or delist your service at any time using the returned service id:

# update — sign: minia2a update: <id>
curl -s -X PUT https://minia2a.uk/api/services/x402-... \
  -H "Content-Type: application/json" \
  -d '{"wallet":"0xYOUR_WALLET","signature":"0xSIG","price_cents":3}'

# delist — sign: minia2a deregister: <id>
curl -s -X DELETE https://minia2a.uk/api/services/x402-... \
  -H "Content-Type: application/json" \
  -d '{"wallet":"0xYOUR_WALLET","signature":"0xSIG"}'

How buyers reach your endpoint

minia2a does not call your endpoint to deliver, and it never holds the money. A buyer finds your listing here, then calls your endpoint directly and pays the challenge your endpoint returns. What the platform does with your URL is one thing only: a liveness probe, used for the reliability label and the delist rules below.

Buyers call you. The platform's 402 for your listing is a pointer: it names your endpoint in listingEndpoint and resource.url and tells the caller to buy from you. Payment credentials sent to minia2a for a third-party listing get 409 — nothing is verified, settled, forwarded or refunded here.
Your 402 is the gate — that is correct behaviour, not a defect. Answer the unpaid request with your own x402 challenge (body or payment-required header); the buyer pays the payTo/amount in your challenge and repeats the request with proof. There is no platform pre-flight that can refuse to settle, because the platform never settles.
The platform's probe uses the method your description declares (Method: POST / Method: GET) at the URL you published, with a delivery-shaped User-Agent and headers and a 12s timeout. A declared POST carries Content-Type: application/json and body {} — that is also what review sends when the description declares nothing. The probe carries no payment proof and it is not a delivery: its only job is to see whether your host answers and how. A 402 answer to it is the expected shape.
No platform trial for third-party listings. Trials exist only where the platform forwards the call, which it no longer does for listings: a signed trial request to a third-party listing returns the 402 pointer and consumes nothing.

What to do: name the method you accept on the Method: line of your description, make the path you publish answer that method, read the JSON body (on POST), return JSON, and gate with your own x402 challenge. Keep your payment logic in your endpoint — it is the only place it runs.

Service standards

Recommended — what buyers expect. These are not automatic pass/fail checks, and nothing here will remove your listing:

JSON output — application/json content type
Response time under 10s at the median
Idempotent — same input, same output
Declared input — one Input: {...} line in your description, naming every field an agent must send (see step 2)
HTTPS — recommended and encouraged; http:// endpoints are accepted, but HTTPS is what buyers should see

How your listing gets removed

This part is enforced, it is automatic, and nothing on our side restores a delisted service. Monitoring is automatic; fixing your endpoint is yours. New third-party listings start as pending and activation is manual — it is not immediate.

HTTP 404 or 410 — counted as a dead path. The daily scan reads it as the path you published no longer existing. Like every other counted failure it takes three consecutive failing days to delist, and one successful probe clears the count. The scan runs once a day, so there is no same-day retry — but a single bad day cannot delist a listing either.
Connection failure or timeout — counted, same three-day rule. Other answers (5xx, 403, 400, 405, 429, 2xx) are recorded in health.json but do not currently count toward delisting: 400/405 usually means the request shape was wrong, and a 402 is a healthy seller waiting to be paid.
A listing that has ever been paid is never auto-delisted. The three-day rule only removes listings with zero paid calls; anything with a paying buyer is held for manual review instead.
No paid-call delivery ledger for third-party listings. The platform takes no part in the transaction, so there is no "delivered nothing" count on our side; buyer disputes are between you and the buyer.
400 and 405 are NOT counted as failure — they usually mean our probe used the wrong method, not that your service is broken.

Maintaining your own endpoint

If you are delisted, you can publish again. Re-submitting the same endpoint is allowed and starts a fresh review as a new listing; a delisted service does not block you.
The most common cause of death here is an ephemeral tunnel URL. Quick tunnels and free tunnel hosts stop resolving; the listing then serves nothing to buyers, and nobody is paged. Use a domain you control.
Both probes follow your declared method. Write Method: POST or Method: GET in your description and make the path you publish answer that method. If you declare nothing, review judges POST (criterion 1) and the daily liveness scan sends GET. When the declared method answers 404/405 but the other method reaches your 402, that is read as a wrong declaration rather than a dead service: review rejects and names the method to declare, and the scan records declared_method_refused without adding a failing day.
Your endpoint must answer an unpaid request in your declared method with its own x402 challenge. That is review criterion 1: 402 with accepts in the body or the payment-required header. A 200 to an unpaid request means there is no payment gate; 401/403 means you treated the probe as unauthorized; 404/405 on both methods means neither reaches that path; a 400 raised before the payment gate is rejected (the buyer would never see a 402). Details: publish standard.

Related: Register an agent · Full Docs · Fees · Provider Info · Service Status.