Codex Web-to-JSON documentation

All endpoints live under https://codeximmortal.com/functions.

Authorization: Bearer w2j_<your key>
Content-Type: application/json

The key is issued at the extraction console and shown once. It is scoped to one buyer balance. Knowing an email address, order id, or client reference unlocks nothing.

GET /web_to_json_product returns the price, unit, published limits, consumption rules, the sample output and the endpoint map.

curl https://codeximmortal.com/functions/web_to_json_product

POST /web_to_json_checkout with { "email": "buyer@company.com" } returns url (Stripe-hosted), orderId and reference. The price and unit count are server-owned; sending amount, price, currency or units is rejected with a 400.

No endpoint here charges a card or accepts a payment token. An agent may open this URL for its customer, but the customer completes payment. There is no autonomous-purchase handshake.

POST /web_to_json_access with { "token": "<from receipt>" } returns api_key the first time, plus the balance. Pass { "rotate": true } to replace a lost key.

POST /web_to_json_extract with { "url": "https://example.com/pricing", "idempotency_key": "optional-label" }.

curl -X POST https://codeximmortal.com/functions/web_to_json_extract \
  -H "Authorization: Bearer $W2J_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://basecamp.com/pricing","idempotency_key":"q4-scan"}'

Synthetic example — demonstrates the response schema:

{
  "job_id": "6ae53de520a4e849608231d7",
  "status": "completed",
  "charged_units": 1,
  "balance": 49,
  "result": {
    "plans": [ { "name": "Business", "price": 49, "currency": "USD",
                 "price_basis": "per_seat", "billing_interval": "month",
                 "billing_commitment": "annual", "minimum_seats": null,
                 "usage_allowance": null,
                 "evidence": "$49 per user/month, billed annually" } ],
    "warnings": ["Minimum seat requirement was not found."],
    "source_url": "https://basecamp.com/pricing",
    "retrieved_at": "2026-10-31T01:12:44.000Z"
  }
}

Reuse the same idempotency_key to retrieve the original job — it returns idempotent_replay: true and charges nothing.

GET /web_to_json_balance returns balance, lifetime totals and the 20 most recent jobs. GET /web_to_json_job?id=<job_id> returns one stored result. A job belonging to another buyer is a 404.

Save a vendor list once and the worker re-checks it on a schedule. Every scheduled check spends one prepaid extraction per URL. There is no subscription, no renewal, and no automatic top-up.

POST /web_to_json_watch
  { "action": "create", "label": "Procurement shortlist",
    "urls": ["https://vendor-a.com/pricing", "https://vendor-b.com/pricing"],
    "cadence": "weekly" }

  { "action": "list" }
  { "action": "get",    "watch_id": "…" }
  { "action": "pause",  "watch_id": "…" }
  { "action": "resume", "watch_id": "…" }
  { "action": "delete", "watch_id": "…" }

Limits: 10 URLs per watch, 5 active watches per account. A full cycle costs urls.length units, and a run stops mid-cycle once the balance reaches zero, reporting insufficient_capacity rather than silently skipping pages.

A change is reported only where the baseline and the fresh extraction both establish a value. Everything else is returned as a reasoned note: FIELD_NOT_ESTABLISHED, PLAN_NOT_IN_CURRENT_EXTRACTION, NEW_PLAN_NOT_IN_BASELINE, PAGE_KIND_CHANGED, EXTRACTION_INCOMPLETE. The first run records a baseline and claims no changes. Reports are stored and readable through the watch endpoint; nothing is emailed yet.

Agent clients map these operations onto tools:

• get_web_to_json_product → GET /web_to_json_product
• get_capacity_purchase_options → GET /web_to_json_product (price and units only; never charges)
• get_extraction_balance → GET /web_to_json_balance
• extract_pricing_page → POST /web_to_json_extract
• get_extraction_result → GET /web_to_json_job?id=
• list_price_watches → POST /web_to_json_watch { action: "list" }

The configured MCP catalog is external to this application and authenticated execution through it has not been verified. Treat MCP as discovery-only. Use the HTTPS endpoints above for supported extraction, balance, result, and monitoring operations. Capacity is bought by the customer at hosted checkout, never by an agent.

A job reserves one credit before the page is fetched, then settles: a completed extraction returning at least one plan record consumes it; a rejected URL, unsupported page, fetch failure or empty extraction releases it.

• JavaScript-rendered pages: Not supported. The worker reads the served HTML, so client-rendered pricing tables return unsupported.
• Maximum page size: 2 MB of HTML. Larger pages are rejected before extraction.
• Fetch timeout: 15 seconds per request, including up to 3 validated redirects.
• Plans per page: Up to 12 plan records, in page order.
• Redirects: Followed only when the destination is also a public HTTPS URL. Private and internal hosts are blocked.
• Caching: No request caching. Every paid job fetches the page live.

• JavaScript-rendered pricing tables (the worker reads served HTML).
• Private-network, internal or IP-literal destinations.
• Authentication bypass or access to restricted systems.
• Client-set prices, units, credits or entitlements.
• Reading another buyer's jobs, results or balance.

Page text is treated as untrusted data. Instructions found inside a fetched page are never executed or followed by the worker.