Two new external x402 services: weekly stock trend indicators and Hijri date conversion
Two quick look-ups an assistant runs in the middle of a chat—one for a stock it is asked about, one for a date in the Islamic calendar—each paid per call and each bought once before we listed it.
What the two services do
| Service | Provider | What the agent gets | Price per call |
|---|---|---|---|
| Weekly stock trend indicators | Stock Trends | The latest weekly snapshot for one listed stock: trend classification and how long it has held, relative strength, volume tag, price changes, moving averages and 52-week range | 0.0035 USDC |
| Hijri date converter | Qist | One Gregorian date in the Umm al-Qura Hijri calendar, with day, month, year, Arabic and English month names and a formatted Arabic date | 0.01 USDC |
Both appear under “Selected external services” on /explore, and agents find them through the MCP tools genesispay_discover_external and genesispay_describe_external_service. They are not GenesisPay merchants. The directory shows each one as an external x402 service from an independent provider, with its sources and the date of its paid check.
Two small jobs in one chat
Put a stock in context. Asked “how is IBM doing?”, an assistant can call GET https://api.stocktrends.com/v1/indicators/latest?symbol_exchange=IBM-N and get one JSON snapshot from the most recent trading week: the trend category Stock Trends assigns, how many weeks it has held, relative strength against the market and the price against its moving averages. The assistant can answer with numbers instead of a guess. The snapshot describes the past week; it does not predict the next one, and it is not a recommendation to buy or sell.
Plan around the Islamic calendar. A shop that ships to customers in the Gulf, or an owner who wants a reminder before Ramadan, needs dates in the Hijri calendar. GET https://api.qist.info/api/hijri?date=2026-10-13 returns that day in the Umm al-Qura calendar, with the month name in Arabic and English. Some communities start a month by moon sighting rather than by this calculated calendar, so a date can differ by a day locally.
Together, the two calls cost 0.0135 USDC. Each is a separate signed payment, and each passes through the owner’s spending policy—by default 5 USDC per payment and 20 USDC per day. Nothing is prepaid, and the assistant can stop after any step.
What “purchase-tested” means
Before listing each service we checked its payment offer, recorded the provider’s payment address and price, and then bought one call with a synthetic example request on 13 October 2026. Each purchase was paid on Base and returned a complete JSON result of the expected shape.
One paid check establishes that, on that day, the endpoint accepted a payment and delivered a result. It does not establish:
- the accuracy or completeness of what a later call returns;
- that every paid request will be delivered;
- that the price or the provider will stay the same.
When an agent buys, GenesisPay reads the live payment offer again and refuses it if the address or price no longer matches what we recorded—before anything is signed. The owner’s agent wallet then pays the provider directly; GenesisPay does not hold the money at any point. The JSON result stays retrievable for seven days through genesispay_result, so a lost chat message never means paying twice.
Why these two
Each answers a question an assistant is asked in ordinary conversation, takes exactly one parameter and returns one small JSON answer. We still add external services a few at a time, and each one is bought once before it is listed. How we check them is described in our first post on external x402 services.
Primary sources
Check the original sources.
- 01x402 Bazaar overviewCoinbase Developer Platform
- 02x402 protocol specification and reference flowx402 Foundation
- 03Stock Trends API documentationStock Trends
- 04Qist x402 service catalogQist
Last source review: Oct 13, 2026. This is technical education, not financial or legal advice.
