ReplyNodes

Quickstart

Set FETCHER_API_KEY in your shell from a real ReplyNodes key. This is the environment variable used by the checked-in gateway CLI; the HTTP API itself only receives the value in the Authorization header. Keep it server-side; do not commit it or put it in browser code.

: "${FETCHER_API_KEY:?Set FETCHER_API_KEY to a real ReplyNodes API key}"

Fetch a public page as clean Markdown. This is the canonical webcontext scrape operation in the OpenAPI contract:

curl -sS \
  -H "Authorization: Bearer ${FETCHER_API_KEY}" \
  "https://api.replynodes.com/v1/webcontext/scrape?url=https%3A%2F%2Freplynodes.com"

Successful responses use the { data, meta } envelope. meta.request_id is always present. Errors use { error: { code, message, request_id } }.

Add correlation

Send an opaque request id when you need to connect a client log to a support investigation:

curl -sS \
  -H "Authorization: Bearer ${FETCHER_API_KEY}" \
  -H "X-Request-Id: demo-scrape-001" \
  "https://api.replynodes.com/v1/webcontext/scrape?url=https%3A%2F%2Freplynodes.com"

Exclude telemetry (optional)

If you do not want telemetry captured for a request, add the optional, client-controlled header:

curl -sS \
  -H "Authorization: Bearer ${FETCHER_API_KEY}" \
  "https://api.replynodes.com/v1/webcontext/scrape?url=https%3A%2F%2Freplynodes.com"

This header is telemetry-only. It does not affect authentication, billing or credits, rate limits, provider execution, or response behavior. Do not encode it as a query or URL parameter.

For parameters, response schemas, and every available provider operation, use the API Reference. It is generated from the checked-in spec, not hand-maintained endpoint prose.

On this page