Forem: Anh Nguyen

AliExpress API Stress Test: 200 Requests, 100% Success Rate, and What It Means for AI Agents

Anh Nguyen — Sun, 26 Apr 2026 13:42:06 +0000

The Problem

AliExpress Open Platform is powerful but not always stable. Intermittent 502 errors, timeouts, and connection resets are common. For an AI agent that needs to make purchasing decisions based on price data, every error is a potential failure.

The Solution

We built AgentShare with automatic retry logic, OAuth 2.0 with auto-refresh tokens, and HMAC-SHA256 signature to talk directly to AliExpress IOP.

The Test

200 consecutive requests
5-second delay between calls
Real AliExpress product IDs
Production endpoint

The Result

Metric	Result
Success Rate	100.00% (200/200)
HTTP 502 (after retry)	0
502 lines in raw log	28 (all auto-retried)
p50 latency	808 ms
p95 latency	985 ms

Key Insight

Reliability is the hidden currency in agent-driven markets.

During this test, AliExpress returned 28 intermittent errors. But from the client's perspective? 100% success rate. Because every error was automatically retried.

Agents don't care about your infrastructure problems. They only care about whether they get a response. If your API returns 502 even once, an agent might mark you as "unreliable" and switch to a competitor.

What's Next

✅ Official AliExpress partnership
✅ OAuth 2.0 with auto-refresh tokens
✅ HMAC-SHA256 signature
✅ Fallback crawl mechanism
🔜 Commission tracker for agents (let agents earn from their own affiliate links)

Try It Yourself

API: agentshare.dev/api/v1/integrations/aliexpress/affiliate/product-detail
Free tier: 100 requests/month, no credit card required
MCP support: Plug directly into Claude Desktop or Cursor
Docs: agentshare.dev/docs

Ask Me Anything

Have you built an integration with AliExpress or other marketplaces? What's your experience with their API stability? Let's discuss in the comments.

{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "AliExpress API Stress Test: 200 Requests, 100% Success Rate, and What It Means for AI Agents",
"description": "We stress-tested our official AliExpress affiliate API. Result: 100% success rate from client perspective, with 28 upstream errors auto-retried. Production-ready for AI agents.",
"author": {
"@type": "Person",
"name": "Anh Nguyen",
"url": "https://github.com/anhmtk"
},
"publisher": {
"@type": "Organization",
"name": "AgentShare",
"url": "https://agentshare.dev",
"logo": "https://agentshare.dev/static/logo.png"
},
"datePublished": "2026-04-26",
"mainEntityOfPage": "https://dev.to/anh_nguyen/aliexpress-api-stress-test-200-requests-100-success-rate",
"keywords": "AliExpress API, AI agents, price API, MCP, stress test",
"about": {
"@type": "SoftwareApplication",
"name": "AgentShare API",
"applicationCategory": "DeveloperApplication",
"url": "https://agentshare.dev",
"softwareVersion": "1.0.0",
"featureList": "AliExpress integration, OAuth 2.0, HMAC-SHA256, auto-retry, MCP support",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD",
"description": "Free tier: 100 requests/month"
}
}
}

#aliexpress #api #aiagents #stressTest #mcp #showdev

One Week Later: What I Learned from Launching an AI Agent API and a Curated MCP Registry

Anh Nguyen — Thu, 23 Apr 2026 14:43:15 +0000

A follow-up on AgentShare: reliability as the hidden currency, why I built a registry, and what 168 "Karma" on an agent-only social network taught me.
Let’s be honest. I launched AgentShare – a price infrastructure API for AI agents – a week ago. The post got some traction. People liked the idea. But I quickly learned that shipping a REST API is only half the battle.

1. The MCP shift was faster than I expected

Developers don’t want to read documentation. They want to plug and play. Within days of adding an MCP server (mcp-remote https://agentshare.dev/mcp), I saw people using it directly inside Cursor, Claude Desktop, and even playing with it in automation scripts. The friction almost disappeared.

If you’re building for AI agents, MCP is not optional anymore. It’s the USB-C of this ecosystem (and Anthropic’s Model Context Protocol is quickly becoming the standard).

2. I built a curated registry

The next realization? Finding quality, actually-working MCP servers is a scavenger hunt. Most directories are noisy, unverified, and full of dead links.

So over the last few days, I built a small curated MCP registry at agentshare.dev/registry.

Every listing is editor-reviewed before going live.
No API key required to browse – simple, machine-readable JSON endpoints (GET /api/v1/registry/entries).
It’s a closed, high-signal list for data, operations, and commerce-adjacent tools.

Right now it features my own AgentShare MCP, a few official reference servers, and placeholders for common patterns (analytics pipelines, web scraping, Slack ops). I’d love to see what the community submits next.

3. Reliability really is the hidden currency

I’ve been running my agent agentshare_claw on Moltbook – a social network where AI agents talk to each other.

Here’s what I learned:

Agents ignore ads, banners, and affiliate links.
They care about structured JSON, freshness_status, and data_age_seconds.
They also reward uptime and predictable error responses.

We’re currently tracking 168 Karma on Moltbook. No hype. Just utility. "Reliability as a currency" is not a slogan – it’s a measurable economic signal. (Just ask who fills the orders when price data goes stale.)

4. Feedback I’d love from you

I’m not here to sell. I’m here to learn.

Is the JSON response shape easy to work with in your agent framework?
How old is “too old” for a price in your use case?
What hardware or component categories are you missing?

The goal is to build a B2A platform (Business to Agent) that honestly serves the agent economy. Not AI wrappers. Actual infrastructure.

Try it:

API: agentshare.dev – Free tier: 100 requests/month, no credit card required.
MCP registry: agentshare.dev/registry
Talk to @agentshare_claw on Moltbook.

Learn. Build. Iterate.

#aiagents #mcp #showdev #edgecomputing #api

I Built a Price Infrastructure API for AI Agents — Here's What I Learned

Anh Nguyen — Tue, 21 Apr 2026 04:28:37 +0000

A few months ago, I had a simple question: why is it so hard for AI agents to get reliable, structured product prices?

LLMs can reason about almost anything — but ask one "what's the cheapest Raspberry Pi 5 right now?" and it either hallucinates a number or admits it doesn't know. The data exists on marketplaces. The problem is the bridge between that data and the agent.

So I built AgentShare — a price infrastructure API designed specifically for AI agents, not human users.

How it fits together (one picture)

Rough pipeline: crawl & normalize → store with timestamps → REST API → MCP tools. The API is the stable contract; crawlers and coverage can evolve behind it. That separation is what lets an agent depend on shapes and freshness instead of scraping HTML on every turn.

The core idea

Most price comparison tools are built for browsers: ads, affiliate banners, SEO-optimized pages. An agent doesn't need any of that. It needs:

Structured JSON, not HTML to parse
Freshness signals, not just a number
Predictable error shapes it can act on
A stable interface it can call repeatedly

AgentShare is built around those four things.

What it looks like in practice

Security: treat X-API-Key like any secret — environment variables or a secrets manager, not committed files or screenshots. The examples below use YOUR_KEY as a placeholder.

curl -H "X-API-Key: YOUR_KEY" \
  "https://agentshare.dev/api/v1/offers/best?q=nvidia+jetson+orin"

Example response (abbreviated):

{
  "status": "ok",
  "data": {
    "best_offer": {
      "price": 4875000,
      "source": "tiki",
      "availability": true,
      "crawled_at": "2026-04-15T02:00:20Z",
      "data_age_seconds": 86400,
      "freshness_status": "stale"
    },
    "summary": "Best price at Tiki — 4,875,000₫"
  },
  "meta": {
    "remaining_requests": 99,
    "freshness_status": "stale"
  }
}

Every response includes freshness_status — fresh, stale, or expired — so the agent can decide whether to caveat its answer or ask for a refresh.

Quota: responses expose remaining_requests in meta on supported routes. The free tier is 100 requests per month with no credit card; plan agent behavior (retries, caching) accordingly.

When auth or limits bite: missing or invalid keys typically yield 401; exceeding quota often yields 429 with a clear message — your agent should backoff and surface that to the user instead of looping.

MCP support

If you're building with Claude Desktop, Cursor, or any MCP-compatible client, you can connect AgentShare as a tool server in one step:

{
  "mcpServers": {
    "agentshare": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://agentshare.dev/mcp",
        "--header", "X-API-Key: YOUR_KEY"
      ]
    }
  }
}

Keep the key out of version-controlled config: use your client's env substitution or local overrides if available.

Tools exposed: price_search, best_offer, best_offer_under_budget, service_meta.

Each tool returns two content blocks: a one-line human-readable summary and a full JSON payload — so the agent has both a quick answer and machine-parseable data in the same response.

Three technical decisions worth sharing

1. Freshness metadata is not optional

A price from six days ago is not the same as a price from two hours ago. An agent recommending a product without knowing data age is doing the user a disservice.

Every response includes crawled_at, data_age_seconds, and freshness_status. The agent can use this to decide whether to add a caveat, trigger a refresh, or tell the user this price is a few days old.

2. "Not found" is not one problem — it's two

Early on, a missing product returned a generic NOT_FOUND error. An agent receiving that has no idea what to do next.

Now the API distinguishes:

{
  "status": "no_data",
  "reason": "out_of_coverage",
  "coverage_url": "https://agentshare.dev/coverage",
  "suggestions": ["similar product A", "similar product B"]
}

{
  "status": "no_data",
  "reason": "pending_crawl",
  "estimated_available": "2026-04-22T00:00:00Z"
}

out_of_coverage → the agent redirects or tells the user clearly.
pending_crawl → the agent knows to try again later.

3. The async deadlock I almost shipped

FastMCP handler calling the REST API with requests.get() — synchronously — inside an async handler on a single Uvicorn worker. The tool call would hang for exactly 120 seconds before failing.

Root cause: the synchronous HTTP call blocked the event loop, which meant the inbound REST request never got processed, which meant the MCP tool call waited forever.

Fix: move all API calls inside MCP tools to asyncio.to_thread() so requests runs on a thread pool, freeing the event loop.

If you're building MCP servers with FastMCP on a single worker, watch out for this pattern.

Current focus areas

I'm honest about what's covered well versus what's still being built.

High quality, updated regularly:

AI edge hardware: Raspberry Pi, NVIDIA Jetson, Orange Pi, Google Coral, Rockchip SBCs
Mini PCs: Intel NUC, Beelink, GMKtec
Components: SSD, RAM, power supplies, cooling
Robotics: kits, servo motors, arms, LiPo/LiFePO4 battery packs

Expanding (beta — data may be incomplete):

Mobile phones, tablets, general consumer electronics

The focus list reflects what matters most to people building AI agents locally — the folks running LLMs on edge hardware or sourcing parts for robot projects.

Full coverage spec: agentshare.dev/coverage

What I'd genuinely like feedback on

Response shape — is the current JSON easy to work with in your agent framework, or are there fields you'd add or remove?
Freshness thresholds — how old is "too old" for a price recommendation in your use case?
Coverage gaps — what hardware or component categories are you looking for that aren't covered yet?

Try it

Docs: agentshare.dev/docs
Free tier: 100 requests/month, no credit card required
OpenAPI spec: agentshare.dev/openapi.json
Agent discovery: agentshare.dev/agent.json

This is a solo project, shipped in public — I build iteratively and rely heavily on good tooling (including AI-assisted development) to move fast. If the approach helps what you're building, or something is broken or confusing, I'd genuinely like to know.