Markdown Fetch API

At a glance

Markdown Fetch API offers URL-to-Markdown conversion with a small cryptocurrency payment attached to each request through x402. It is relevant to agents that already have payment infrastructure and need readable page text. For an ordinary scraper or a first integration, payment setup and inconsistent header documentation make it a less direct starting point.

Good fit

A developer comparing per-request access for an existing payment-capable agent. The documented API takes a URL and returns Markdown, or a JSON wrapper containing content and fetch metadata. The potential benefit is a single fetch-and-convert endpoint without a conventional subscription, provided the payment handshake and conversion quality meet your needs.

Consider something else when

You need an unpaid converter, authenticated-page access or a proven answer for complex JavaScript pages. A request without payment returned HTTP 402, so the public endpoint did not provide a free conversion sample. The inspected documents also disagree on the payment-proof header, which needs resolving before an implementation can be called ready.

Start here

Read /openapi.json and /llms.txt, then inspect an unsigned GET /fetch?url=https%3A%2F%2Fexample.com response without supplying a wallet or payment proof. The trial returned Payment required and accepted-network information. Before paying, confirm the current x402 client and header: OpenAPI names x-payment, while llms.txt names PAYMENT-SIGNATURE for v2.

Cost and requirements

The homepage lists 0.01 USDC per request on Base or 0.005 USDC on SKALE Base, consistent with the two offered amounts in the unpaid response. A successful request requires the supported payment arrangement, not merely an API URL. The total cost of funding and operating that arrangement was not measured.

Limits to know

Only the unpaid payment gate was tested. No converted content, JavaScript rendering, extraction quality, timeout charging or refund behaviour was established. Target URLs go to an external fetching service, so avoid private links or credentials until its handling is clear. It merits a bounded integration investigation for an already payment-capable agent, rather than a general recommendation to switch fetching workflows.

Still unclear

• Which payment-proof header and x402 client version are currently supported?
• Are failed fetches charged, and what refund behaviour applies?
• How are requested URLs and fetched content retained?