URL to Markdown API
Fetches a web page and returns the article as clean markdown, with its title, byline and final URL.
Raw HTML is mostly navigation, scripts and markup an agent pays for in tokens and then has to strip itself; this returns only the article, as markdown with headings, lists and resolved links, fetched through an SSRF-safe client that re-checks every redirect.
01Request
POST /v1/url-to-markdown
content-type: application/json
payment-signature: <base64 x402 payload>
{
"url": "https://kitchen-ledger.blog/posts/weekday-starter",
"max_chars": 2000
}Without the payment-signature header the call answers 402 with the payment requirements, including this endpoint's price and its max_timeout_seconds, so the deadline is known before anything is paid. The payment is verified before the handler runs and settled only after it succeeds, so a call refused by the gate, or one that fails inside the handler, is never settled. The single case we cannot state for you is a settlement call that fails without answering: the error message says so when that is what happened.
02Call it from code
// url-to-markdown: $0.002 per call, paid in USD Coin on eip155:8453 via x402
// Install: npm install @x402/fetch@2 @x402/evm@2 viem@2
// Save as client.mjs (ES module, Node 18+), export EVM_PRIVATE_KEY with the paying wallet's key in your shell, then run: node client.mjs
// The wrapper reads the 402 (payment-required), signs and retries with payment-signature.
import { wrapFetchWithPayment, x402Client, decodePaymentResponseHeader } from '@x402/fetch'
import { ExactEvmScheme } from '@x402/evm/exact/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.EVM_PRIVATE_KEY)
const client = new x402Client().register('eip155:8453', new ExactEvmScheme(account))
const fetchWithPayment = wrapFetchWithPayment(fetch, client)
const body = {
"url": "https://kitchen-ledger.blog/posts/weekday-starter",
"max_chars": 2000
}
const res = await fetchWithPayment('https://grist.tools/v1/url-to-markdown', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify(body),
})
console.log(res.status, await res.json())
const settle = res.headers.get('payment-response')
if (settle) console.log(decodePaymentResponseHeader(settle).transaction)# url-to-markdown: $0.002 per call, paid in USD Coin on eip155:8453 via x402
# Install: pip install "x402[requests,evm]>=2.24,<3"
# The session reads the 402 (payment-required), signs and retries with payment-signature.
import os
from eth_account import Account
from x402 import x402ClientSync
from x402.http import decode_payment_response_header
from x402.http.clients.requests import x402_requests
from x402.mechanisms.evm.exact import register_exact_evm_client
from x402.mechanisms.evm.signers import EthAccountSigner
account = Account.from_key(os.environ["EVM_PRIVATE_KEY"])
client = x402ClientSync()
register_exact_evm_client(client, EthAccountSigner(account), networks="eip155:8453")
session = x402_requests(client)
payload = {
"url": "https://kitchen-ledger.blog/posts/weekday-starter",
"max_chars": 2000
}
res = session.post("https://grist.tools/v1/url-to-markdown", json=payload)
print(res.status_code, res.json())
settle = res.headers.get("payment-response")
if settle:
print(decode_payment_response_header(settle).transaction)# url-to-markdown: $0.002 per call, paid in USD Coin on eip155:8453 via x402
# 1. Unpaid call: HTTP 402, the requirements in the payment-required header (base64 JSON) and in the body.
curl -i -X POST 'https://grist.tools/v1/url-to-markdown' -H 'content-type: application/json' -d '{"url":"https://kitchen-ledger.blog/posts/weekday-starter","max_chars":2000}'
# 2. Same call with the signed payment (an EIP-3009 authorization, EIP-712 signed: it cannot be
# typed by hand). x-payment is accepted as the v1 alternative. HTTP 200 carries payment-response.
curl -i -X POST 'https://grist.tools/v1/url-to-markdown' -H 'content-type: application/json' -H 'payment-signature: <base64 x402 payload>' -d '{"url":"https://kitchen-ledger.blog/posts/weekday-starter","max_chars":2000}'03Response
200 OK
payment-response: <base64 settlement receipt>
{
"title": "Feeding a Sourdough Starter on a Weekday Schedule",
"byline": "Marta Rinaldi",
"excerpt": "A feeding routine that keeps a rye starter active on a nine-to-five schedule, with ratios and timings.",
"site_name": "Kitchen Ledger",
"lang": "en",
"markdown": "By [Marta Rinaldi](https://kitchen-ledger.blog/authors/marta-rinaldi/)\n\nMost starter guides assume you are home all day, ready to feed every twelve hours on the dot. A starter kept on a weekday routine can stay just as lively, provided the flour, the ratio and the temperature do the work that a flexible timetable cannot.\n\n## The ratio that buys you time\n\nA stiffer, less frequently fed starter ferments more slowly. Feeding one part starter to five parts flour and five parts water stretches the peak from four hours to roughly ten at a kitchen temperature of twenty-two degrees, which is long enough to cover a working day.\n\n- Morning, before work: discard all but 10 g and feed 50 g flour and 50 g water.\n- Evening: use the starter at its peak, or refrigerate it overnight.\n- Weekend: return to two feeds a day at one to one to one if you plan to bake.\n\n## Choosing the flour\n\nWhole rye ferments faster and more predictably than white wheat, so a small share of it keeps a slow schedule from stalling. The [guide to flour protein](https://kitchen-ledger.blog/guides/flour-protein/) explains why, and the [baker's percentage tables](https://www.bakerspercentage.net/tables) help when you scale a recipe up.\n\nIf the starter smells sharply of acetone by evening, it is hungry: shorten the interval or lower the temperature rather than adding more flour at once.",
"length": 1368,
"truncated": false,
"readability_applied": true,
"url_final": "https://kitchen-ledger.blog/posts/weekday-starter",
"fetched_at": "2026-09-26T09:30:00.000Z"
}This example is illustrative: it shows the exact shape the handler returns, but it was not produced by a reproducible call, because the real answer depends on live network data that changes over time.
04Input schema
The same schema the handler validates against, published from the same source. Also served, free, at/v1/url-to-markdown/schema.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"url": {
"type": "string",
"maxLength": 2048,
"format": "uri",
"description": "Page to fetch, http or https. Redirects are followed and every hop is checked against private and reserved addresses."
},
"max_chars": {
"default": 50000,
"description": "Cut applied to the returned markdown, counted in Unicode code points.",
"type": "integer",
"minimum": 200,
"maximum": 200000
}
},
"required": [
"url"
],
"additionalProperties": false
}05Errors
| Code | HTTP | When |
|---|---|---|
| invalid_input | 400 | The body does not match the schema on this page. Nothing is charged. |
| blocked_target | 403 | The destination is refused by the network guard: a disallowed address, or, for HTTP requests, a scheme other than http/https, a port other than 80/443, or credentials in the URL. |
| unreachable_target | 424 | The destination you named did not resolve or refused the connection. |
| upstream_status | 424 | The destination you named answered with a status this endpoint cannot use. |
| upstream_timeout | 424 | The destination you named did not answer before the declared timeout for this endpoint expired. |
| unsupported_content_type | 415 | The destination returned a type this endpoint does not handle. |
| too_large | 413 | The response exceeded the size cap while streaming, or decompressed at more than the allowed ratio. |
| unprocessable | 422 | The bytes arrived but could not be processed, for instance a malformed document. |
| internal | 500 | Our fault, and in almost every case nothing is charged. The exceptions come after the call has run and the settlement call was made: the message "The work was done but settlement could not be completed", and the messages starting with "Payment settlement returned". There, whether the payment moved is unknown to us as well. The payment moves at most once: its nonce is single-use and settlement is idempotent, so a retry with it is never charged twice. A retry is normally refused with a 402: replay_consumed, an expiry reason, or a reason saying the nonce was already used once the transfer is on-chain. Only if our server restarted before the transfer was final can a retry run the call again. Even then, the payment moves at most once. To see whether it was settled, read the EIP-3009 authorizationState of its nonce on-chain; to call again, sign a new payment. |
| rate_limited | 429 | Too many calls from the same payer, or too many calls towards the same destination domain. Nothing is charged. |
| concurrency_limit, registry_at_capacity, upstream_unavailable | 503 | We could not serve the call right now. Retryable: wait the number of seconds in the retry-after header, then repeat the call. concurrency_limit and registry_at_capacity mean we were at capacity: the call did not run. You can send the same payment again if its validBefore is still far enough away to cover another call. If it is not, the retry gets a 402 authorization_validity_too_short: sign a new payment. upstream_unavailable means our internal service failed or did not answer in time: the call may already have run and the payment may have been settled. A retry with the same payment can get a 402 whose error field says why. authorization_validity_too_short: too little time is left before validBefore to cover another call. This check comes before the replay check, so it does not tell whether the first payment was settled. replay_consumed (the payment was used and may have been settled) or replay_exhausted (too many attempts): sign a new payment. replay_in_flight: the first call is still running, so wait and do not pay again. invalid_exact_evm_nonce_already_used: the transfer is already on-chain, so this payment cannot move again. Sign a new payment. An authorization can be settled only once, since its nonce is single-use. To see whether it was settled, read the EIP-3009 authorizationState of its nonce on-chain. |
| misconfigured | 503 | The service is not configured to serve calls. The call did not run and nothing is charged. It needs a fix on our side, so there is no retry delay to wait for. |
06Questions
- What does a call to url-to-markdown cost?
- $0.002 per call, paid via x402. An unpaid call answers 402 with the price and max_timeout_seconds, so both are known before anything is paid.
- How long can a call take?
- The handler has 12 s to answer. The 402 envelope declares max_timeout_seconds as 33: that timeout plus payment verification and settlement around it.
- What happens if the call fails?
- The payment is verified before the handler runs and settled only after it succeeds, so a call that fails inside the handler is not settled. The errors table in section 05 lists each code, its HTTP status and when it is raised.
- Where is the input schema?
- In section 04 on this page, and served free at /v1/url-to-markdown/schema. It is the schema the handler validates against, also published in /openapi.json.